


Nyár van, uborkaszezon, a fű se nő. 
Nekünk valahogy mégsem okozott 
problémát a címlapsztori kiválasz- 
tása. Jelentjük: 2005. július 6-án az 
Európai Parlament 648 nem szava- 
zattal, 14 ellenében, 18 tartózkodás 
mellett elvetette a számítógéppel 
megvalósított találmányok szaba- 
dalmazására vonatkozó (ismertebb 
nevén: szoftverszabadalmi) irányelv- 
tervezetet. 

Nyugodjék békében. Aki pedig kíván- 
csi szegény pórul járt törvényjavaslat 
tündöklésének és bukásának történe- 
tére, nos az elolvashatja Dr. Dudás 
Ágnes mekrológját . 

Augusztusi számunkban egyelőre 
még dominálnak a komolyabb 
szakmai tartalommal bíró írások, 

de -— nem kis örömünkre — az előző 
számunkban közzétett felhívásra, 
melyben a lap arculatváltásához új 
cikkírókat kerestünk sokan jelentkez- 
tek. A weblapunkon közzétett téma- 
lista (2 http:[/www.linuxvilag.hu/ 
szerzoknek) így azóta számos új 
elemmel bővült, illetve szaporodnak 
a téma , foglaltságát" jelző pluszok is. 


Jó szerzőből természetesen soha 
nem elég, így továbbra is várjuk 

a javaslatokat, észrevételeket, 

de legfőképpen a lelkes cikkszer- 
zők jelentkezését 

a szerkesztoseg(olinuxvilag.hu címen. 
Régi szerzőink sem pihentek. 

Több korábban indult sorozat is 
folytatódik ebben a számban. Auth 
Gábor a FreeBSD, Fülöp Balázs a Java 
programozás, Komáromi Zoltán 

a PEAR, Garzó András pedig a számí- 
tógép-hálózatok alapjainak bemuta- 
tásával lépett tovább, illetve befejező 
részéhez érkezett Fábián Zoltán 
eFltk-ról szóló sorozata. 

Többen kérdezték, így itt is meg- 
erősítjük: ezek a sorozatok termé- 
szetesen a megújult lapban is folyta- 
tódnak. Ugyanakkor ahogy ígértük, 
szándékunk szerint szeptembertől 
egyre gyakoribbak lesznek a kife- 
jezetten felhasználóknak szóló 
tartalmak is. 


Addig is kellemes időtöltést, 
jó szórakozást kíván 
a Linuxvilág stábja. 


0 Kiskapu Kft. Minden jog fenntartva 


0 Kiskapu Kft. Minden jog fenntartva 





Belekotyogók fóruma 

A SourceLabs új — vagy inkább újabb -—, 
közösségi, nyílt forrású fejlesztési ter- 
vezeteket összefoglaló webhelyet indí- 


y 
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tott Swik névvel. A SourceLabs nyílt 
forrású programokra alapuló tanács- 
adói és támogatási tevékenységet vé- 
gez, nyilatkozatuk szerint több ügyfe- 
lüktől is kaptak olyan visszajelzést, 
miszerint nincs olyan webhely, ahol 
teljes értékű megoldások összeállításá- 
hoz kényelmesen lehetne nyílt alkal- 
mazásokat gyűjteni. A többi hasonló 
webhely közül a Swik azzal próbál 
kitűnni, hogy Wiki jellegű eszközöket 
biztosít a fejlesztőknek, akik a rend- 
szeren belül tárolt tervezetek bárme- 
lyikének adataiba belenyúlhatnak, 
módosíthatják és frissíthetik azokat. 
A hozzászólások azonnal meg fognak 
jelenni a rendszerben, és a cég nem 
fogja moderálni azokat — ez első hal- 
lásra veszélyes lehetőségnek tűnik, 
de a SourceLabs tapasztalatai szerint, 
néhány deviáns személyt leszámítva, 
a közösség képes önmaga szabályozá- 
sára. A webhely további szolgáltatása 
lesz az RSS alapú értesítés az egyes 
tervezeteket érintő változásokról. 

A Swik egyelőre kevesebb, mint ezer 
tervezetet tartalmaz, ám a várakozá- 
sok szerint a közeljövőben ez a szám 
meredeken nőni fog. 

5 www.swik.net 





a SourceLabs project 


Csere-bere az Operában 

Az Opera Software bemutatta BitTorrent 
ügyféllel ellátott böngészőjének előze- 
tes változatát. A 8.02-es Operát Win- 
dows, Linux és Mac OS X alá tölthetjük 
le, és ez az első olyan böngésző, amely 
önmagában, külön ügyfélprogram nél- 
kül teszi lehetővé az egyenrangú fájl- 
csere-hálózat használatát. Az Opera fej- 
lesztői ezzel veszélyes vizekre eveztek: 
a program ilyen irányú bővítése a fel- 
használók körében ugyan népszerű 
lehet, ám a jogvédelemért felelős szer- 
vezetek és a ,komoly" cégek körében 
aligha; a rajta folyó illegális zene-, film- 
és programcsere miatt a kiadók és a ha- 
tóságok az utóbbi időben komolyan 
felléptek a BitTorrent hálózat ellen. 

3 www.opera.com 
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iPod Linux 

Cinikusan mondhatnánk, az iPodot is 
utolérte a sorsa: készült hozzá Linux- 
terjesztés. Az iPod Linux állítólag 

— a legújabb modellek kivételével — 
könnyedén telepíthető, mindössze 

5 MB tárhelyet igényel, és természete- 
sen elérhetően hagyja a készülék ere- 
deti operációs rendszerét is. Legfonto- 
sabb előnye, hogy a gyári szolgáltatá- 
sokkal ellentétben kiváló minőségű, 
akár 16 bites, 96 kHz-es, sztereó hang- 
felvételek készítését is lehetővé teszi. 
Az iPod Linux képes a JPEG, a GIF és 





a BMP fájlok fekete-fehér megjeleníté- 
sére, több egyszerű játékot, valamint 
számológépet és naptárat is tartalmaz. 
Fejlesztése jelenleg is folyik, hamaro- 
san iPod-iPod hálózatok létrehozására, 
Game Boy emulátor futtatására és 
Doomozásra is alkalmas lesz. Fontos 
megjegyezni, hogy az iPod Linux 
hanglejátszási szolgáltatásának minő- 
sége az uClinux korlátai miatt egyelőre 
elmarad az eredetitől. 

2 www.ipodlinux.org 


Mint az úthenger 

Alig fejezte be a brazil Conectiva felvá- 
sárlását, illetve a névváltást, az ex- 
Mandrakesoft Mandriva máris újabb 





linuxos vállalatot olvasztott magába: 
a Lycorist. Az amerikai székhelyű 
Lycoris különösen felhasználóbarát, 
elsősorban asztali gépekre készített 
terjesztéseiről ismert, felvásárlása 
valószínűsíthetően — a Conectiva meg- 
szerzéséhez hasonlóan - a piacszer- 
zést szolgálja. A Lycoris terjesztései 


Észak-Amerikában nagy népszerűség- 
nek örvendenek, és széles körben 
kaphatók mind dobozos formában, 
mind számítógépekhez mellékelve. 

A Mandrakesoft, mint emlékezetes, 
tavaly tavasszal még csődvédelembe 
volt kénytelen menekülni, most vi- 
szont minden jel szerint az előre me- 
nekülés és az agresszív terjeszkedés 
is belebukott már néhány vállalat. 

A Lycoris beolvasztása alighanem 
könnyen ment, ugyanis az amerikai 
vállalat is komoly gondokkal küzdött, 
az utóbbi időkben több fejlesztését is 
meg kellett szakítania, illetve munka- 
társainak számát is csökkentette. A fel- 
vásárlás nyomán az eljövő években 
várhatóan különféle részeket fognak 
átemelni a terjesztések között, majd 

a cégek operációs rendszerei és szol- 
gáltatásai fokozatosan összeolvadnak. 
3 www.mandriva.com 

2 www.lycoris.com 


Kattintani tud? Plusz egy pont 

A California State Lniversity segédrek- 
tora, Lorie Roth fontos felfedezést tett: 
attól, hogy a diákok mindennapjaik 
során számtalan feladatra használják az 
internetet, még nem feltétlenül képesek 
az általa kínált lehetőségek valóban 
hatékony kiaknázására. Bepötyögni 

a bennünket érdeklő téma kulcsszavait 
a Google-be, elektronikus leveleket írni 
ismerőseinknek, MP3 fájlokat töltögetni 
— ezek kétségtelenül közelebb visznek 
ahhoz, hogy megbarátkozzunk a szá- 
mítógéppel, ugyanakkor nem hozzák 
magukkal a megbízható információk 
felkutatásának, illetve a talált adatok 
ellenőrzésének képességét. Márpedig 
ezek a képességek manapság ugyan- 
olyan fontosak, mint a számolás, az 
olvasás vagy éppen az írás képessége 

— véli az egyetemi vezető. Éppen ezért 
kidolgoztak és már , tesztelnek" is egy 
tesztet, amellyel a diákok informatikai- 
technológiai-olvasási képességeit, 
összefoglaló néven Internet IO-ját kí- 
vánják felmérni. Az eredményeket ha- 
marosan arra is fel kívánják használni, 
hogy az egyetemre felvett, e tekintet- 
ben társaikhoz képest lemaradóban 
lévő diákokat rövid továbbképzésre 
küldhessék. A dolog fontosságát mi 
sem jelzi jobban, mint az az adat, mely 
szerint az amerikai diákok már évek óta 
többet használják az internetet, mint 

a hagyományos könyvtárakat. 














Magmodell 

A Software Revolution elkészült a 2.6-os 
Linux rendszermag részletes, LIML 2.0 
alapú modelljével. Az összekapcsolt, 





szabadon méretezhető, vektorgrafiku- 
san ábrázolt elemekből — folyamatáb- 
rákból, szerkezeti diagramokból, álla- 
potgépekből, hívási táblázatokból, dön- 
tési táblákból stb. — álló modell és a hoz- 
zá tartozó szöveges leírások a rendszer- 
mag minden fontosabb alrendszerét le- 
fedik, ide értve a forráskódban található 
mezőket és függvényeket is. A cég sze- 
rint ez a Linux rendszermagról valaha 
készült legteljesebb és legrészletesebb 
modell; melyet egyébként egy SVG- 
nézegető beépülő modul birtokában 
bárki szabadon böngészhet. A progra- 
mozás iránt érdeklődőknek érdemes 
lehet akár csak kíváncsiságból belenéz- 
niük, nagy kapufát nem lőhetnek vele. 
2 http:/www.softwarerevolution.com/ 
jeneral/open-source-docs.html 


GeForce 7800 

A grafikus vezérlők világában ma még 
különlegességnek számító újdonságo- 
kat hoz magával az NVIDIA hamaro- 





san az üzletekben is megjelenő GeForce 
7800 GTX vezérlője. Bár szolgáltatásai- 
ban kevéssé fog különbözni a 6800-as 
sorozat tagjaitól, felépítésében már 
jóval fejlettebbnek mutatkozik náluk. 
A lapka egyik érdekessége, hogy az 
egyes részei képesek lesznek egymás- 
tól eltérő órajelekkel üzemelni, így pél- 
dául a képpont- és a raszterfeldolgozó 
430, míg a vertexkezelő részegység 470 
MHz-en üzemel. A műszaki csemegék 
iránt kevésbé fogékonyakat persze 
nyilván inkább az érdekli, hogy az 
alapórajel módosításával a másik órajel 
is módosul, vagyis e tekintetben nem 
kell a tuningolási lehetőségek elveszí- 
tésétől tartani. A 24 darab képpontfu- 
tószalag, a 8 vertexfutószalag, a 300 
millió tranzisztor és a jelenlegi csúcs- 


www.linuxvilag.hu 





modell GeForce 6800 Ultrához képest 
mért 50 százalékos teljesítménybővü- 
lés pedig magáért beszél. 

3 www.nvidia.com 


Ot 4 

Újabb mérföldkőhöz érkezett a norvég 
Trolltech: elkészült ismert keresztplat- 
formos fejlesztőeszközének, a Ot-nek 
legújabb, 4-es változatával. A Ot 4 segít- 
ségével összetett, ügyfél- és kiszolgáló- 
oldali alkalmazásokat egyaránt lehet fej- 
leszteni, a Microsoft Visual Studio .NET- 
tel egybeépítve, illetve az új licencelési 
módozat révén pedig a kereskedelmi, 
windowsos alkalmazásokat készítők is 
könnyebben kihasználhatják lehetősé- 
geit. A Ot 4 új, nagyteljesítményű, szük- 
ség esetén lecserélhető grafikus motort 
kapott; kiterjesztették többszálú futtatá- 
si képességeit; valamint javítottak a se- 
bességén és a memóriakezelésén. A Ot 4 
a GPL fejlesztések számára ingyenesen, 
a kereskedelmi munkákhoz pedig fize- 
tős változatban máris elérhető, összesen 
háromféle — Ot Console, Ot Desktop Light 
és Ot Desktop — variációban. 

3 wwwi.trolltech.com 


Beért az Nvu 

Végre-valahára elkészült a nyílt forrá- 
sú weblapszerkesztő, az Nvu 1.0-s vál- 
tozata. A hónapok óta béta változatok 
formájában készülődő kiadás olyan is- 
mert alkalmazások babérjaira tör, mint 
a Microsoft FrontPage és a Macromedia 
Dreamweaver. A WYSIWYG, vagyis 
,amit látsz, azt kapod" jellegű szer- 
kesztő készítői mindent meg is tettek, 
hogy méltó vetélytársai legyenek 

a nagyoknak, az Nvuu 1.0 kiváló stabili- 
tással és teljesítménnyel, beépített he- 
lyesírás-ellenőrzővel, CSS-szerkesztő- 
vel és kiterjedt súgóval rendelkezik, 
szigorúan igazodik a HTML 4.01 és az 
XHTML 1.0 szabvány előírásaihoz, va- 
lamint a lehető legtisztább kódot állít- 
va elő böngészők széles választékával 
biztosítja az együttműködést. Az Nvu 
1.0 több nyelven is elérhető, illetve 
nemcsak Linux, de Windows, FreeBSD, 
OS/2 és Mac OS X alatt is futtatható. 

2 www.nvu.com 


Medgyesi Zoltán 
(mz€rettesoft.hu) 

A Linuxvilág hírszerkesztője. 
Szabadidejét legszívesebben 
a barátnőjével tölti, szeret 
autózni és bográcsban főzni. 
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Mi újság a rendszermag fejlesztése körül? 


A Linux rendszermag fejlesztésében jelenleg egyre 
inkább előtérbe kerül az üzembiztosság kérdése. 
Greg Kroah-Hartman és Chris Wright önkéntesen 
elvállalta egy szigorúan ellenőrzött üzembiztos fa 
gondozását. Régebben az üzembiztos és a fejlesztői 
fák éves hosszúságú ciklusokban 
váltották egymást, az új üzembiztos 
fa azonban a fejlesztői mellett 
fog futni, és kizárólag a fon- 
tos hibajavításokat fogja 
tartalmazni. A Linus 
Torvalds-féle 2.6.11-es 
kiadást tehát egy 2.6.11.1- 

es és egy 2.6.11.2-es 

követte, illetve Greg és 

Chris részéről további 
üzembiztosságot növelő 
kiadások is megjelentek. 

A 2.6.11.z fa üzembiztosságának 
növelése a 2.6.12 kiadása után is 
folytatódni fog, ahogy majd lesz egy 
2.6.12.1-es kezdetű sorozat is. A korábbi 
üzembiztos sorozatokkal ellentétben, amelyeknek 
karbantartói meglehetősen nagy szabadsággal 
rendelkeztek a tekintetben, hogy mely foltokat 
kívánják befogadni, most szigorú szabályok 
határozzák majd meg, hogy mi kerülhet be az 
üzembiztos ágba; sőt, azt is pontosan meg fogják 
határozni, hogy mennyi időnek kell eltelnie a foltok 
beadása és elutasítása vagy elfogadása között. 
Linus az üzembiztos fát egyszerűen , szivatós" fának 
nevezte, hiszen nincs olyan ép elméjű ember, aki 
szívesen felvállalta volna a karbantartásával járó 
gondokat. Chris és Greg azonban nem rettentek 

el a kihívástól, bár a pontos folyamatok egyelőre 
csak kialakulóban vannak. Úgy tűnik azonban, hogy 
az üzembiztosság ismét kiemelt szerepet kapott 

a Linux fejlesztésében. 


A SysFS fájlrendszer sorsa az utóbbi időben kissé 
bizonytalanná vált. Fejlesztését elsősorban az 
ösztönözte, hogy meg kellett szabadulni a ProcFS 
régről maradt terhétől, illetve a környékén uralkodó 
fejetlenségtől, és valami letisztult, ésszerű dolgot 
kellett — volna — a helyére illeszteni. A fejlesztők 
remélték, hogy tiszta lappal indulva a régi hibákat el 
lehet majd kerülni. Nemrég azonban a rendszermag- 
gal foglakozók rájöttek, hogy a SysFS könyvtárainak 
egyike rossz helyre került: a /sys/block könyvtárnak 
valójában /sys/Class/blocknak kellene lennie! Hiába, 
késő! Időközben komoly mennyiségű felhasználói 
kód készült úgy, hogy a könyvtár meglévő elérési 
útját vette figyelembe. Greg Kroah-Hartman, ha 
vonakodva is, de kénytelen volt beismerni, hogy 

a SysFS inkonzisztenciáját nem lehet kijavítani. 


A SysFS szeplőtlen arcán megjelentek az első ráncok. 










A SguashFS továbbra is igyekszik a rendszer- 
magba, illetve próbálja teljesíteni az elvárásokat, 
miközben vezető fejlesztője, Phillip Lougher egyre 
inkább gyűlöli a világot. Az előrelépés egyik 
akadálya talán inkább a kultúrák eltérőségéből 
fakad: a rendszermag fejlesztői 
valamilyen meggyőző érvet 
szeretnének hallani a beépítés 
mellett, míg Phillip inkább 
a kódolás, semmint az 
,eladás" iránt érdeklődik. 
A többi akadály inkább 
műszaki jellegű. Például 
jelenleg a SguashFS 
legfeljebb 4 GB-os fájlok 
kezelésére képes. 
Persze, mivel a SguashFS 
tömörített fájlrendszer, 
a valóságban ez inkább 
8 GB-nyi adatot jelent. 
Nemrég az is kiderült, hogy 
a readdir() sem a ./, sem a ../könyvtárat 
nem adja vissza a SguashFS esetében, ahogy 
azt gyakorlatilag az összes szabványos fájl- 
rendszernél megszokhattuk. Ezek a problémák 
— továbbiak mellett — sajnos komolyan hátrál- 
tatják a SguashFS-t a normál rendszermag 
részévé válásban. 


A FUSE (Filesystem in USErspace, fájlrendszer 
felhasználói térben) várhatóan bekerül a fő 
rendszermagfába, miután időzött egy kicsit 
Andrew Morton -mm ágában. A FUSE sok 
mindenen ment már keresztül, Linus Torvalds 
például sokáig úgy tartotta, hogy egy felhasználói 
térben futó fájlrendszer eleve elvetélt ötlet, soha 
semmi értelmes nem fog kisülni belőle. A FUSE 
ennek ellenére tetszetős motorrá fejlődött, 

és a jelek szerint ellenzői is elcsitultak. Andrew 
is pártolja, és számíthatunk rá, hogy Linus előtt 
is támogatni fogja. 


Több tervezet is gazdát cserélt az utóbbi időben, 
illetve egyes programok karbantartói mostanában 
nyertek hivatalos elismerést. Pete Zaitcev lett az 
USB blokkos illesztőprogram és a Yamaha PCI 
hangillesztőprogram hivatalos gondozója. Herbert 
Xu átvette James Morris társgondozói helyét 

a rendszermag crypto APl-jának fejlesztésében. 
Gerd Knorr felhagyott a Video4Linux 
karbantartásával, amivel a tervezet pillanatnyilag 
gazdátlanul maradt. 


Zack Brown 


Linux Journal 2005. július, 135. szám 
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Játékok a vásárban 





A 4. Információtechnológiai és telekommunikációs vásár idén megújult formában 


kerül megrendezésre a Budapesti Nemzetközi Vásárral egy időben. Tavaly több min 


120 ezres közönség érkezett a BNV-re a HUNGEXPO Budapesti Vásárközpontba. 


agy érdeklődés mellett zajlottak a tavalyi 

INFOmatket PC-s és konzolos bajnokságai is, 

ezért idén — 2005. szeptember 17. és 25. között — 
a látogatókat minden eddiginél több játék és bajnokság 
várja kilenc napon át. 


Vadászpilóták bajnoksága 

Az INFOmarketen központban szerepel a GAME szekció, 

a játékok nagy választékával. A közönség 2005-ben először 
kísérheti figyelemmel a repülőgép szimulátorok bajnokságát 
a ,B" pavilonban. A Jet-Fly Légiharc Kupa budapesti döntő- 
jére szeptember 23-25. között kerül sor. A szeptember 17-19-i 
előselejtezők, valamint a bajnokság izgalmas pillanatait a lá- 
togatók kivetítőről nézhetik. A jelentkező vadászpilóták to- 
vábbi információkat találnak a 5 www.jetfly.hu honlapon. 


FIFA 2005 — World Cyber Games 

A hétköznapokon mindenki kipróbálhatja a játékokat, 

a hétvégéken, pedig szurkolhat a bajnokságok résztvevői- 
nek: az első hétvégén a World Cyber Games - Counter-strike 
offline selejtezők versenyzőinek, a következő hétvégén, 
pedig a látogatók részesei lehetnek a FIFA 2005 Bajnokság 
szoros mérkőzéseinek. Hasznos tudnivalók a jelentkezésről 
megtalálhatóak: a 5 http:/hu.worldcybergames.com, 

és a 9 www.fifahungary.com honlapokon. 


Újdonságok a kínálatban 

A kiállításra elhozza újdonságait többek között Magyarország 
legnagyobb konzolforgalmazója. A GAME szekció mellett 

a KLASSZIKUS, azaz a hagyományos kiállításon a felhaszná- 
lók megismerhetik a legmodernebb vírusirtó programokat, 
irodai-, ügyviteli- és nyelvoktató szoftvereket. Ezen kívül 
megtalálhatóak a hagyományos hardvertermékek, a legújabb 
MP3 lejátszók, valamint vetítéstechnikai berendezések. 
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nGépészek" a fedélzeten 

Az INFOmarket-INFOtrenden először kerül megren- 
dezésre a Magyar Tuning és Modding Kiállítás és 
Verseny (a tuningbarátoknak ugyanakkor az idei 

már a negyedik találkozója lesz). A számítógép tervezők 
paradicsoma egyedi építésű számítógépekkel várja 

a nagyközönséget. 


Kilenc nap kikapcsolódás 

Az INFOmarket szeptember 17-25. között az egész 
család számára betekintést nyújt a játékok világába, 
az informatika és telekommunikációs piac kínálatába. 
A játékos bajnokságokat a párhuzamosan zajló BNV 
szórakoztató programjai egészítik kia HUNGEXPO 
Budapesti Vásárközpontban. 


További információ: 
2 wwwinfomarket.hu 
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WhisperStation 

A Microway bemutatta új, első- 
sorban tervezési alkalmazásokhoz 
és kis- és középméretű fürtökbe 





szánt WhisperStation munkaállo- 
mását. A WhisperStation kettő 
darab AMD Opteron vagy Intel 
Xeon EMGA4T processzorral, 
NVIDIA FX1300 PCI Express grafi- 
kus vezérlővel, 2 GB memóriával, 
különösen csendes ventilátorok- 
kal és tápegységgel rendelkezik, 
valamint 207-os Viewsonic LCD 
monitor tartozik hozzá. 

A WhispersStation 64 bites Red 
Hat, SUSE vagy Gentoo Linuxszal 
vagy Microsoft Windowszal kap- 
ható. A vásárlók pontos és egyedi 
igényeinek megfelelően további 
bővítésére is van lehetőség, pél- 
dául nagyméretű merevlemezek- 
kel, RAID-del és célprogramokkal. 
www.microway.com 


Comet12 hordozható 
számítógép 

A Tadpole Computer Comet12-je 
egy a Federal Information 
Processing Standards (FIPS) 140- 
2 előírásainak megfelelő, vezeték 
nélküli hordozható számítógép, 
elsősorban kormányzati használat- 
ra. A Tadpole vezeték nélküli, 
ultravékony Sun Ray ügyfeleinek 
Comet termékvonalára és 

a Fortress Technologies biztonsá- 
gos vezeték nélküli átjáróira épül- 
ve a Comet12 biztonságos, titko- 
sított vezeték nélküli kapcsolatot 
biztosít az érzékeny adatokat is 
továbbító szövetségi hálózati és 
távközlési rendszerrel. 

A Comet12-ben felhasznált megol- 
dások védik a felhasználók adatait, 
hozzáférés-vezérlést, illetve esz- 
köz- és készülékhitelesítést biztosí- 
tanak, valamint az adatkapcsolati 
rétegbeli védelemmel biztonságot 
nyújtanak a szolgáltatásmegtaga- 
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dási támadásokkal szemben. 
A Comet12 12,1"-os TFT-LCD XGA 
kijelzővel rendelkezik, 26,4 x 22,1 x 
2.3 cm méretű, súlya pedig 1,5 kg. 
www.tadpolecomputer.com 


PRIMEGUEST kiszolgálók 


A Fujitsu Computer Systems beje- 
lentette új, Intel Itanium 2 pro- 
cesszorokra épülő PRIMEOUEST 
kiszolgáló-termékvonalát. 

A PRIMEGUEST kiszolgálók adat- 
központ szintű hibatűrésre képe- 
sek, és magas szintű rendszer- 
méretezhetőséget biztosítanak az 
olyan az iparágban széles körben 
elterjedt környezetek számára, 
mint a Red Hat Enterprise Linux, 
a Novell/SUSE Linux Enterprise 
Server és az Itanium alapú számí- 
tógépekhez készült Windows 
Server 2003. A PRIMEOUEST ki- 
szolgálókat felépítésüknél fogva 
kiváló hibatűrés jellemzi, akár 
nyolc magas rendelkezésre állású, 
teljesen független, önálló kiszol- 
gálóként üzemeltethető, hardvere- 
sen elválasztott partíció kezelésé- 
re is alkalmasak. A PRIMEOUEST 
kiszolgálók lapkakészlete által biz- 
tosított tükrözési szolgáltatás és 
a rugalmas be- és kiviteli képes- 
ségek szintén a magas rendelke- 
zésre állás elérését segítik. 

A PRIMEGUEST kiszolgálók re- 
dundáns, SSL protokollt alkalma- 





zó felügyeleti hálózattal, beépített 
gigabites kapcsoló és hub össze- 
köttetésekkel, beépített SCS/ me- 
revlemezekkel és a partíciók fel- 
ügyeletének megkönnyítésére 
szintén beépített KVM/USB 
egységgel rendelkeznek. 

us. fujitsu.com/computers 


Orion PMC vagy PMI 

A Curtiss-Wright Controls 
Embedded Computing új, kétcsa- 
tornás videótömörítő és -kibontó 
kártyát mutatott be Orion névvel. 
A kártya PMC és PC! foglalatba il- 
leszkedő kivitelben egyaránt elér- 
hető, tehát VME, CompactPClI és 
asztali PCI rendszerekbe egyaránt 
beépíthető. Az Orion kettő darab 
beépített JPEG 2000 motorral 
rendelkezik, amelyekkel teljes mé- 
retben képes a szabványos, 625 
soros PAL és az 525 soros NTSC 
kompozit videóanyagok kódolásá- 
ra. Beviteli módban az Orion leg- 
feljebb tíz ,egyvégződésű" vagy 
négy különbözeti, analóg PAL 
vagy NTSC videóbemenet fogadá- 
sára képes, ezek közül kettőt le- 
het egyidejű JPEG 2000 tömöri- 
tésre kiválasztani. Kiviteli módban 
az Orion egy vagy két JPEG 2000 
adatfolyamot fogad a 64 bites, 66 
MHz órajelű PC/ buszon keresztül, 
kibontja az adatfolyamokat, majd 
kiadja a kapott egy vagy két, füg- 
getlen PAL vagy NTSC videojelet 
— erre a hátlapon elhelyezett, 20- 
as MDR aljzat szolgál. A videó- 
rögzítő és -felvevő rendszer része- 
ként a kapott tömörített videófo- 
lyamokat helyben is el lehet men- 
teni, de távoli megjelenítés céljá- 
ból hálózaton keresztül is lehet 
terjeszteni. Az Orionhoz a Power- 
PC alapú Linuxokhoz jár illesztő- 
program, illetve más rendszerek- 
hez is léteznek kiegészítők. 

Az alacsony szintű illesztő- 
program- és az átfogó kártyatá- 
mogató könyvtár számos C függ- 
vényt foglal magába, ezeket több- 
féle operációs rendszerre és gép- 
típusra is át lehet ültetni. Az Orion 
PMC és PCI kivitelben érhető el. 
http:/Avww.cwcembedded.com 
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RTOS eszközmeghajtók illesztése 


beágyazott Linuxhoz 


Alakítsuk hagyományosan durva és kusza RTOS kódunkat szépen formázott 


Linux eszközmeghajtókká. 


Linux viharként tört be a beágyazott rendszerek 
A piacára. Az ipari elemzők szerint az új beágyazott 

32- és 64-bites tervek fele-egyharmada a Linuxra 
épít. Több alkalmazási területet már most is a beágyazott 
Linux ural (például SOHO hálózatok és a képalkotó/több- 
funkciós perifériák), de öles léptekkel halad a tárolórend- 
szerek (NAS/SAN), a digitális otthoni szórakoztatás (HDTV/ 
PVR/DVRI/STB) és a kézi/vezeték nélküli készülékek elsősor- 
ban a digitális mobiltelefonok piaca felé is. 
A beágyazott Linux alkalmazások persze nem Minervát utá- 
nozva pattannak ki a fejlesztők fejéből. A legtöbb projekt- 
hez több ezer vagy akár több millió soros örökölt forráskód 
szükséges. Igaz ugyan, hogy beágyazott rendszerek százai 
sikeresen hozták át Linux alá a már meglévő kódot (jó pél- 
da erre a Wind Rivers VxWorks vagy a pSOS, VRTX, 
Nucleus és más RTOS rendszerek) a módszer gyakorlata 
azért még nem teljesen kitaposott út. 
Mind a mai napig az örökölt RTOS alkalmazások áthozata- 
lával foglalkozó irodalom nagy része az RTOS API-ra, fel- 
adatkezelésre és ütemező modellekre és ezek Linux felhasz- 
náló térbeli megfelelőire koncentrál. Az erősen [/D-függő 
beágyazott programozási témában legalább ilyen fontos az 
RTOS alkalmazás alkatrész csatoló kódjának a szabványos 
Linux eszközmeghajtó modellhez igazítása. 
Cikkünkben a hagyományos beágyazott alkalmazásokban 
leggyakrabban használt memóriatérkép alapú [/D megköze- 
lítéseket szeretnénk sorra venni. A kiszolgáló rutinok (ISR) 
és felhasználói-szálak alkatrész eléréseinek ad hoc szerű fel- 
használásától kezdve egészen a bizonyos RTOS eszköztárak- 
ban megtalálható félig-tormális meghajtó modellekig jutunk 
el. Bemutatjuk azokat a heurisztikus és egyéb módszereket 
melyekkel az RTOS kódot szépen formázott Linux eszköz- 
meghajtóvá alakíthatjuk. A cikkünk különös figyelmet szen- 
tel az RTOS kód és a Linux memória belapozási eltéréseinek, 
a sor alapú [I/O sémák átírásának, valamint részletesen fog- 
lalkozunk az RTOS I/O, helyi Linux meghajtók és démonok 
számára használható formára hozásával. 


RTOS I/0 megoldások 
Számos RTOS alapú rendszerben alkalmazott [/O techniká- 
ra leginkább talán a , kötetlen" szó illik. A legtöbb RTOS ré- 
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1. ábra Tipikus I/O és adatküldés összehasonlítása hagyományos 
RTOS és Linux rendszerekben 


gebbi MMU nélküli processzorokra készült, így aztán akkor 
is figyelmen kívül hagyják a memóriakezelést, ha története- 
sen van MMU és nem tesznek különbséget a logikai és fizi- 
kai címzés között. A legtöbb RTOS teljes egészében privile- 
gizált módban (rendszer módban) fut, ami látszólag növeli 
a teljesítmény. Mint ilyen, az RTOS alkalmazás és rendszer 
kód elérheti a gép teljes címterét, a memóriába lapozott esz- 
közöket és [/O utasításokat. Tulajdonképpen meglehetősen 
nehéz elválasztani egymástól az RTOS alkalmazás kódot 

a meghajtó kódtól, már ahol egyáltalán létezik ilyen meg- 
különböztetés. 

Ez a kötetlen megoldás az [/D megoldások ad hoc jellegű 
felhasználásához és sok esetben a felismerhető meghajtó 
modell teljes hiányához vezet. Az ilyen egyenlőség elvű, 
felosztás nélküli munkakezelés tükrében tanulságos lehet 
megnézni az RTOS-alapú alkalmazásokra vonatkozó né- 
hány kulcselgondolást és gyakorlatot. 


Sorközi (in-line) memóriába lapozott elérés 

Amikor az 1980-as évek közepén megjelentek az üzleti 
RTOS termékek, a legtöbb beágyazott program nagy fő cik- 
lusokat tartalmazott amelyeket az idő-kritikus műveleteket 
kezelő [I/O és ISR beszúrások tarkítottak. A fejlesztők első- 
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2. ábra RTOS feladatok átültetése Linux folyamat alapú szálakká 


sorban a párhuzamosság erősítése érdekében terveznek 
RTOS és végrehajtó vezérlést a projektjeikbe, ugyanakkor 
idegenkedtek bármilyen más szóba kerülő szerkezettől. Így 
aztán még ha az RTOS egyébként lehetővé is tette az [/D 
formalizmust, a beágyazott programozók inkább a sorközi 
[/O utasításokat használták: 


fdefine DATA REGISTER  0XFO0O000OF5 


char getchar(void) 1 
return ("((char ") DATA REGISTER)); 
3 


void putchar(Cchar c) ( 
"((char ") DATA REGISTER) -— c; 
l 


A fegyelmezettebb fejlesztők általában elhatárolták az 
összes ilyen [/O kódot az eszközfüggetlen kódtól, de renge- 
teg [/D spagettivel is találkoztam már. Amikor ilyen erőtel- 
jes sorközi, memóriába lapozott [/O felhasználással talál- 
koznak, a Linux témában zöldfülűnek számító beágyazott 
fejlesztők gyakran kísértést éreznek, hogy a kódot egy az 
egyben átvigyék felhasználói térbe és a regisztercímek 
fdefine megadásait mnapO) hívásokká alakítsák. Ez a meg- 
közelítés bizonyos prototípus megadásoknál jól működik, 
de nem támogatja a megszakításkezelést, korlátozott valós 
idejű érzékenységgel rendelkezik, nem igazán biztonságos 
és üzleti megoldásokban semmiképp sem megfelelő. 


RTOS ISR-ek 

Linux alatt a megszakítás szolgáltatások kizárólag a rend- 
szermag birodalmába tartoznak. RTOS alatt az ISR kód sza- 
bad formájú és visszatérési módján kívül gyakran semmi 
nem különbözteti meg az alkalmazás kódtól. Sok RTOS 
ajánl fel olyan rendszerhívást vagy makrót amellyel a kód 
meghatározhatja saját környezetét. Ilyen például a Wind 
River VxWorks intcontext 0) függvénye. Általános megol- 
dás továbbá, hogy az ISR-ek szabványos könyvtárakat 
használnak, ezáltal további újra-belépési és hordozhatósági 
problémákat vetve fel. 

A legtöbb RTOS támogatja az ISR kódok regisztrációját vala- 
mint magára vállalja a megszakítás elbírálást és ISR indítást. 
Bizonyos primitív beágyazott vezérlők ugyanakkor csak az 
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3. ábra Többágú megközelítés az RTOS kód és API-k Linux átiratához 


ISR kezdőcímek közvetlen illesztését támogatják az alkatrész 
vektortábláiba. Még ha az írási-olvasási műveleteket sorközi 
módszerrel a felhasználói térbe helyezzük is, a Linux ISR 
kódnak mindenképpen a rendszermag térbe kell kerülnie. 


RTOS I/0 alrendszerek 

A legtöbb RTOS testreszabott szabványos C futásidejű 
könyvtárral rendelkezik (ilyen a pREPC a pSOS esetében) 

a ISV-khez pedig szelektíven foltozott C könyvtárakat (/ibc) 
alkalmaz. A glibc-vel is ugyanez a helyzet. Így az RTOS-nak 
legalább a szabványos C-stílusú [/O alapelemeit támogatnia 
kell, ide értve az open, close, read, write és ioct] rend- 
szerhívásokat. A legtöbb esetben ezek a hívások és hozzá- 
tartozóik vékony réteget alkotnak az [/O alapelemek körül. 
Érdekes módon, mivel a legtöbb RTOS nem támogat fájl- 
rendszereket, azok, amelyek Flash vagy forgó médiához 
szánt fájl absztrakciós réteget is tartalmaznak gyakran telje- 
sen más kódot és/vagy API-t alkalmaznak. Jó példa erre 

a pSOS pHILE rendszere. A Wind River VxWorks a legtöbb 
RTOS rendszert lepipálva képességekben gazdag [/O al- 
rendszert is kínál, elsősorban a hálózati csatolófelületek és 
média kapcsán felmerülő nehézségek kezelésének általáno- 
sítása érdekében. 

Sok RTOS támogatja az alsó fél kezelést, azaz, valamilyen 
módszert amivel az [/O feldolgozás átvihető a megszakítha- 
tó és/vagy preemptív környezetbe. Mások nem rendelkez- 
nek ilyesmivel viszont van valamilyen más, hasonló ered- 
ményt biztosító mechanizmusuk, például megszakítás egy- 
másba ágyazás. 


Tipikus RTOS alkalmazás I/0 szerkezete 

Az 1. ábra diagrammja általánosan használt [/D sémát (csak 

bemenet) és adatközvetítési útvonalat mutat be a vezérlő 

alkalmazáshoz. A feldolgozás a következő módon zajlik: 

e az alkatrész megszakítás kiváltja az ISR végrehajtását. 

e AzISR elvégzi az alapfeldolgozást és vagy helyben be- 
fejezi a bemeneti műveletet vagy az RTOS-ra bízza az 
időzített végrehajtást. Bizonyos esetekben a későbbre 
halasztott végrehajtást valami olyasmi kezeli, amit 
Linux alatt felhasználói szálnak itt pedig normál RTOS 
feladatnak nevezünk. 

e Ahol és amikor az adat ténylegesen beérkezik (azaz az 
ISR vagy a lehalasztott környezetben) a kész adatok sor- 
ba rendeződnek. Az RTOS ISR elérheti az alkalmazás 
sor API-t és egyéb IPC-ket - lásd az API táblát. 
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4. ábra Linux hálózati meghajtók blokkdiagrammja 


e Egy vagy több alkalmazás feladat aztán kiolvassa az 
üzenetet a sorból és felhasználja az átadott adatokat. 


A kimenetet gyakran egyedülálló módszerekkel oldják meg 
— awriteO vagy hasonló rendszerhívások helyett egy vagy 
több RTOS alkalmazás-feladat helyez adatokat a sorba. 

A sort aztán egy [/O rutin vagy ISR olvassa be, amely vála- 
szol a küldésre kész megszakításnak, rendszerórának vagy 
más a sor tartalmára várakozó alkalmazás feladatnak. Ez- 
után az [/D műveletet követlenül végzi, szavazva (polled) 
vagy DMA-n keresztül. 


RTOS I/0 hozzárendelés Linux-hoz 

A fent bemutatott sor alapú termelő/fogyasztó [/D model 
csak egy a sok ad hoc megközelítés közül amelyeket az örö- 
költ rendszerek alkalmaznak. Folytassuk ezt az egyszerű 
példát és nézzünk meg néhány további (újrajmegvalósítást 
a beágyazott Linux rendszerben. 

Azok a fejlesztők akik tartózkodnak a Linux meghajtó ter- 
vezés jellemzőinek megismerésétől esetleg akik nagyon si- 
etnek, valószínűleg megpróbálják változatlanul áthozni 

a felhasználói térbe a sor alapú elképzelést. Ebben a meg- 
hajtó beillesztési megoldásban a memóriába lapozott fizikai 
[/O a felhasználói térben jön létre az mmapO által biztosított 
mutató segítségével: 


finclude csys/mman.h: 


fdefine REG SIZE 0x4 

/" eszköz regiszter méret7"/ 
fdefine REG OFFSET 0XFA400000 
/:" az eszköz fizikai címer/ 


void "mem ptr; 

/" visszahivatkozás a memóriába lapozott 
s eléréshez7/ 

int fd; 


fd-open("/dev/mem" , 0. RDWR) ; 
/: nyitott fizikai memória (root-nak kell lenni) "/ 


mem ptr - mmap((void ")0x0, 


"REG AREA SIZE, 
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5 PROT. READ--PROT. WRITE, 

MAP. SHARED, fd, REG OFFSET); 
/: tényleges mmapO hívásr/ 
A folyamat alapú felhasználói szál ugyanazt a feladatot 
látja el, mint amit az RTOS-alapú ISR vagy halasztott 
feladat. Ezt követően az SVR4 IPC msgsndO hívás segít- 
ségével a sorba helyezi az üzenetet, ahonnan valamely 
másik helyi szál vagy folyamat lekérheti azt a msgrcvO 
függvénnyel. 
Az ilyen gyors megoldás a prototípusokhoz ugyan 
elegendő lehet, de fejleszthető kódot készíteni márt 
komolyabb kihívás. Először szóljunk a megszakítások 
felhasználói térbe helyezéséről. A DOSEMU-hoz hasonló 
projektek jelzés alapú I[/D megszakításokat használnak 
a SIG-en keresztül (silly interrupt generator, azaz buta 
megszakításgenerátor) de a felhasználó térbeli megszakí- 
tás kezelés meglehetősen lassú — milliszekundumos 
lappangás a rendszermag alapú ISR pár tíz mikroszekun- 
dumos lappangási idejéhez képest. Továbbá a felhasználói 
környezet ütemezése, még preemptív rendszermag és va- 
lós idejű rendszabályok alkalmazása esetén sem garantál- 
nak 100976-ig valós idejű végrehajtást a felhasználói térbeli 
[I/O megszakításoknak. 
Mindenképpen javasolt, hogy fogjuk meg a dolog vé- 
gét és legalább egy egyszerű Linux meghajtót készítsünk, 
ami a megszakításokat rendszermag szinten kezeli. Egy- 
szerű karakteres vagy blokkos meghajtó közvetlenül elhe- 
lyezheti az alkalmazás adatait a felső félben (top half) 
vagy elhalasztva a feldolgozást átadhatja azokat egy szá- 
lacskának (tasklet), egy rendszermag szálnak vagy a 2.6-os 
rendszermagban az alsó félben (bottom half) megjelent 
munkasor mechanizmusnak. Az eszközt egyszerre több al- 
kalmazás szálfolyamat is megnyithatja szinkronizált olva- 
sást végezve rajta, éppen úgy , ahogy az RTOS alkalmazás 
végzett szinkronizált sorfogadó hívásokat. Ehhez a meg- 
közelítéshez legalább a fogyasztói szál [/O részt újra kell 
írni, hiszen sor fogadó műveletek helyett most eszközol- 
vasást végzünk. 
Amennyiben egyszerűsíteni szeretnénk a beágyazott 
Linuxra átvitelt, meghagyhatjuk a sor-alapú sémát és ké- 
szíthetünk még egy szálat vagy démont amely a frissen 
elkészített eszköz [I/O adataira várakozik. Amikor az adat 
megérkezett, a szál/démon felébred és az adatot feldolgozó 
alkalmazás szál vagy folyamat számára elteszi a sorba. 


Atalakítási megoldások 

Az RTOS kód beágyazott Linuxhoz alakítása alapelveiben 
nem különbözik az üzleti alkalmazások átalakításától. Miu- 
tán az átalakítás logisztikai részével (make/build szkriptek 
és metódusok, a fordító kompatibilitás, helyek, include ál- 
lományok és így tovább) már végeztünk, a kód szintű átala- 
kítás kihívásai tulajdonképpen az alkalmazás szerkezet és 
API használat területére szűkülnek. 

Témánk további megvitatásához tételezzük fel, hogy az 
alkalmazás rész (azaz az [I/O specifikus részen kívül min- 
den) az RTOS-alapú rendszerből egyetlen Linux folyamat- 
tá alakul át. Az RTOS feladatok Linux szálak lesznek a fel- 
adatközi IPC-k pedig Linux inter-process és inter-thread 
megfelelőikkel helyettesítjük. 
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1. táblázat A Linux és az RTOS-ok előjogokhoz kötött utasításai 





IPC-k 


RTOS Alkalmazás Sorok, jelek, levelesládák 


kötetlen megosztott memória 


RTOS Meghajtó Sorok, jelek, levelesládák 


kötetlen megosztott memória 


Sorok, jelek, csővezetékek 
Intra-Process megosztott memória 


Linux alkalmazás 


megosztott rendszer memória 


Linux meghajtó . Megosztott rendszer memória Rendszermag 
(statikus) írható/olvasható folyamatmemória . szemaforok 
forgózárak (Spinlocks) 
Linux modul Megosztott rendszer memória Rendszermag 
(dinamikus) írható/olvasható folyamatmemória szemaforok 


Szinkronizálás 


Szemafórok, mutexek 


Szemafórok, mutexek 


Szemafórok, mutexek 


Feladatkezelés Névtér 


Teljes RTOS feladatkezelés Teljes alkalmazás, 
Repertoire 


(Linkelési időben) 


Teljes RTOS feladatkezelés 
Repertoire 


Könyvtárak és rendszer 


Teljes alkalmazás, 
Könyvtárak és rendszer 
(Linkelési időben) 


Folyamatok és szálak Helyi folyamatok, statikus 


API-k és megosztott könyvtárak 


Rendszermag szálak, 
taskletek 


Teljes rendszermag 


Rendszermag szálak, Modul-szintű és exportált 





askletek rendszermag szimbólumok 


forgózárak (Spinlocks) 


Az átírás alapjait nem nehéz megérteri, a buktató a részle- 
tekben rejlik. A leglényegesebb részlet pedig mind között 
az RTOS API használata, illetve az, hogyan tudjuk megva- 
lósítani Linux szerkezetekkel. 

Amennyiben a projektünk nem időhöz kötött és célunk 
hordozható kódot készíteni későbbi projektfejlesztésekhez, 
akkor érdemes egy kis időt tölteni a jelenlegi RTOS alkal- 
mazás elemzésével és megvizsgálni miképpen illeszkedik 

a Linux elképzelésekhez. Az RTOS alkalmazás kód esetében 
elgondolkozhatunk rajta, át tudjuk-e Linux folyamat-alapú 
szálakká alakítani az RTOS feladatokat egy az egyben 
avagy inkább a teljes RTOS alkalmazást több Linux folya- 
matra bontjuk. Ettől a döntéstől függően meg kell vizsgál- 
nunk a felhasznált RTOS IPC-ket, hogy a helyes intra- 
process vagy inter-process hatáskört válaszuk. 

Meghajtó szinten egyértelmű, hogy valamennyi sorközi 
RTOS kódot megfelelő meghajtókká kell alakítani. Amennyi- 
ben az örökölt alkalmazásunk már eleve szépen felosztott, 
akár RTOS [I/O API-kat használ, akár külön rétegekbe szed- 
ték szét, feladatunk jelentősen egyszerűsödik. Ha viszont az 
ad hoc [/O kód az egész örökölt kódbázisunkban szanaszét 
szórva található saját magunknak kell kiköveznünk az utat. 
Azok a fejlesztők, akik sietősen szeretnék kiszedni az örö- 
költ RTOS kódot vagy akik prototípust akarnak összekala- 
pálni, valószínűbb, hogy megpróbálják a lehető legtöbb 
RTOS API-t helyben Linux megfelelővel kiváltani. Az ele- 
meket általában, akárcsak az egyedi API-kat, IPC-ket és 
rendszer adattípusokat, majdnem teljesen átlátszóan viszik 
át. Mások a ítdefine újradefiniálásban és makrókban hisz- 
nek. A többiek újrakódolják a részeket, ideális esetben egy 
elvonatkoztatási réteg részeként. 

Az API-alapú átalakítást érdemes az emulációs könyvtárak- 
kal érdemes kezdeni, amelyek sok beágyazott Linux terjesz- 
tésnek részét képezik (például a MontaVista könyvtárai 

a Wind River VXWorks és pSOS rendszerekhez) avagy olyan 
harmadik féltől származó API-átírat csomagokat használ- 
nak, mint amilyet például a MapuSoft kínál. 
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A legtöbb projekt hibrid megközelítést alkalmazza: az 
összes egyedi vagy könnyen megvalósítható API-t áthozza, 
újraszerkesztik azokat a részeket, ahol az nem okoz lassu- 
lást majd csapd-le-a-vakondokot módszerrel addig foltoz- 
zák a maradék kódot amíg le nem fordul és fut. 


A rendszermag és a felhasználói tér elérhető API felületei 
Akár a teljes újratervezést, akár a gyors de felületes API 
megközelítést választjuk, az RTOS alkalmazásunkat és az 
[/O kódot szét kell osztanunk, hogy az illeszkedjen a Linux 
rendszermag és felhasználói tér elképzeléshez. Az 1. táblázat 
bemutatja a Linux mennyivel szigorúbb az előjogot igénylő 
utasítások terén mint az örökölt RTOS. Segítségével 
könnyebben elvégezhetjük a felosztási rész. 
Az 1. táblában két pontra különösen felhívnám a fegyelmet: 
e az RTOS-ok egyenlőség pártiak, az alkalmazásnak és az 

[/O kódnak is lehetővé teszi, hogy bármilyen címhez 

hozzáférjen és szinte bármilyen tevékenységet végezzen, 

a Linux ugyanakkor sokkal hierarchikusabb és kötöttebb. 
e — Az örökölt RTOS kód a rendszer valamennyi belépé- 

si pontját és szimbólumát láthatja, legalább linkelés- 

kor, ugyanakkor a Linux felhasználói kód a rendszermag 

kódtól és annak névterétől teljesen elhatárolva készül. 


A Linux előjoghoz kötött eléréshierarchiájának eredménye- 
képpen általában csak a rendszermag kód (meghajtók) érhe- 
tik el a fizikai memóriát. Ha egy felhasználói kód ilyesmit 
szeretne, annak root jogon kell futnia. Általában véve a fel- 
használói tér kódja elhatárolódik a Linux rendszermag kód- 
tól és csak azokat a szándékosan exportált szimbólumokat éri 
el, amelyek a /proc/ksyms alatt látszanak. Továbbá a rendszer- 
mag hívásai nem közvetlenül történnek, hanem a felhaszná- 
lói könyvtár kódon keresztül. Ez a fajta szétválasztás szándé- 
kos, célja a Linux biztonságának és stabilitásának növelése. 
Amikor meghajtót írunk, minden éppen fordítva van. A stati- 
kusan meghajtók a teljes rendszermag névterét látják, nem 
csak az exportokat, ugyanakkor semmilyen rálátásuk nincs 








a felhasználói tér folyamat alapú szimbólumaira és belépési 
pontjaira. Továbbá, ha a meghajtónkat futásidőben betölthető 
modulba csomagoljuk, programunk csak azokat a csatolófelü- 
leteket befolyásolhatja, amelyeket az "EXPORT. SYMBOL" makró 
segítségével kifejezetten exportáltunk a rendszermagban. 


Hálózati meghajtók átírása 

Mint fentebb említettük, karakteres és blokkos eszközök át- 
írása Linux alá időigényes, de viszonylag magától értetődő 
folyamat. A hálózati meghajtók átírása viszont már ijesz- 
tőbbnek tűnik. Ne feledjük, hogy a Linux tulajdonképpen 

a TCP/IP-vel együtt nőtt fel, sok 1990-es évek végén készült 
RTOS már tartalmazott hálózati kódot. Így aztán az örökölt 
hálózatkezelés sokszor csak a képességek vázát tartalmazza, 
azaz csak egyetlen folyamatot vagy példányt kezel egyetlen 
kapun avagy csak a fizikai csatolófelületet kezeli egyetlen 
hálózati médiumon. Néhány esetben a hálózati szerkezetet 
utólag csiszolgatták. Ez történt például a Wind River 
VxWorks MUX kódjával, hogy támogasson több csatolófelü- 
letet és fizikai kapcsolattípust. A rossz hír, hogy valószínű- 
leg újra kell írnunk elég sok, ha nem az összes meglévő há- 
lózati csatolófelületet. A jó hír, hogy a Linux alatti újra fel- 
osztás nem olyan nehéz és példának tucatnyi nyílt forrású 
hálózati kód áll rendelkezésünkre. Átalakítási munkánk fel- 
adata, hogy a 4. ábra alján található részeket megfelelő cso- 
mag formázó és csatolófelület kóddal töltsük fel. 

Hálózati meghajtók készítése nem kezdőknek való feladat. 
Mivel azonban sok RTOS hálózati meghajtó létező GPL Linux 
csatolófelületek forrásából készült, elképzelhető, hogy maga 





a kód segíti elő törekvéseinket. Továbbá, az integrátorok és ta- 
nácsadók elég nagy és egyre bővülő közössége odafigyel és 
üzletet lát a Linux átalakításokat végző beágyazott fejlesztők 
részére nyújtott segítségben. Az áraik is elfogadhatóak. 


Osszefoglalás 

Cikkünk célja, hogy a beágyazott fejlesztőknek egy kis rálá- 
tást nyújtson, milyen kihívások és előnyök várhatóak 
amennyiben teljes programkészletüket Linux alá viszik át 
az eredeti RTOS rendszerről. Persze körülbelül 2.800 szó túl 
kevés rá, hogy igazán elmerüljünk a meghajtóátírás (meg- 
hajtó API-k és buszfelületek címfordítás és egyebek) részle- 
teiben, de a seregnyi meglévő GPL meghajtó kód egyaránt 
szolgál kiváló dokumentációként és sablonként átültetési 
erőfeszítéseink során. Az itt bemutatott irányelvek csapa- 
tunkat kívánják segíteni az RTOS kód linuxos átírásában 
valamint ötletekkel támogatni az eredeti kód beágyazott 
Linux rendszerekhez leginkább illeszkedő újrafelosztását. 


Linux Journal 2004. október, 126. szám 


E cikk írásakor Bi// Weinberg a Strategic Marke- 
ting and Technology Evangelist igazgatójaként 
a MontavVista és beágyazott Linux fejlesztése 
terén szerzett több mint 17 évnyi ipari tapaszta- 
lat tudását összegezte. Kiterjedt tapasztalatok- 
kal rendelkezik a beágyazott valós idejű rend- 
szerek terén és szakértőnek számít az operációs rendszerek, 
eszközök, program licencek és programkészítés témákban. 
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A HTB várakozásisor-kezelési elv elemzése 


Vajon képes a Linux úgy garantálni a szolgáltatásminőséget, hogy egyszerre álljon 
rendelkezésünkre a kívánt sávszélesség, a megadott határt mégse lépjük túl? 


Kipróbáltuk. 


HTB (Hiterarchical Token Buckets, hierarchikus 
A zseton vödrök) várakozásisor-kezelő elv 

— a linuxos forgalomszabályozó megoldások 
egyik eleme - olyan eszköz, mely egyrészt szolgáltatás- 
minőségi (Ouality of Service, 005) funkciókat biztosít, 
másrészt alkalmas a TCP alapú forgalom kifinomult szabá- 
lyozására. Írásomban áttekintem a sorkezelő elv elemeit, 
valamint több előzetes teljesítményteszt eredményeit is 
ismertetem. Ezek elvégzéséhez különféle linuxos környe- 
zeteket állítottunk össze, a forgalomkeltést pedig egy Ixia 
készülékre bíztuk. A próbák során kimutattuk, hogy az 
átviteli sebesség szabályzásának pontossága befolyásolha- 
tó, illetve a sávszélesség körülbelül egy 2 Mbps-os tarto- 
mányon belül szabályozható. A próbák igazolták a HTB 
sorkezelő algoritmusok teljesítményét és pontosságát, va- 
lamint rámutattak bizonyos, a forgalomkezelés javítására 
alkalmas módszerekre. 
A forgalomszabályozási eljárások akkor jutnak szerephez, 
amikor az adott IP-csomag már bekerült a továbbításra váró 
csomagok adott kimenő felülethez rendelt várakozási sorá- 
ba, ám az illesztőprogram még nem kezdte meg tényleges 
továbbítását. Az 1. ábrán látható, hogy a forgalomszabályo- 
zási döntések meghozatalának helyszíne hogyan viszonyul 
a fizikai Ethernet összeköttetésen való továbbításhoz és 
a szállítási rétegbeli protokollokhoz, mint az UDP és a TCP. 
A Linux rendszermag Alexey Kuznetsov által megvalósított 
forgalomszabályozó szolgáltatása négy fő összetevőből áll: 
várakozásisor-kezelő elvek, szolgáltatási osztályok, szűrők 
és házirendkezelés. 
A várakozásisor-kezelő elvek a sorba állított IP-csomagok 
kezelésének módját megadó szoftveres eljárások. Minden 
hálózati készülék ismer valamilyen sorkezelő elvet, ezek 
közül a legelterjedtebb talán a FIFO (First In, First Out, 
elsőként érkező elsőként távozik) algoritmusra alapuló elv, 
melynél a csomagok érkezésük sorrendjében kerülnek be 
a várakozási sorba, mégpedig olyan sebességgel, amilyen- 
nel a sorhoz tartozó készülék képes elküldeni őket. A Linux 
jelenleg is számos sorkezelő elvet támogat, és újabbak hoz- 
záadására is biztosít lehetőséget. 
A sorkezelő algoritmusok részletes leírását az interneten 
,]proute2--tc Notes" (lásd a forrásokat) címmel lehet megta- 
lálni. A HTB elv a hozzárendelt szolgáltatási osztályok sora- 
iba helyezett csomagok kezelésére a TBF algoritmust alkal- 
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mazza. A TBF algoritmus forgalmi házirendkezelési és for- 
galomformálási (traffic-shaping) képességekkel rendelkezik. 
A TBF algoritmus részletes leírása a Cisco IOS Ouality of 
Service Solutions Configuration Guide útmutatójában 

(lásd: , Policing and Shaping Overview", A házirendkezelés 
és a forgalomformálás áttekintése) szerepel. 

Egy-egy szolgáltatási osztály bizonyos házirendszabályo- 
kat határoz meg, ilyen a maximális sávszélesség vagy 

a maximális löket, és a sorkezelő elvet alkalmazza ezen 
szabályok betartatására. Egy-egy sorkezelő elv és osztály 
összetartoznak. Az adott osztály által előírt szabályokat 
egy előre megadott várakozási sorral kell összerendelni. 
A legtöbb esetben minden osztálynak saját sorkezelő elve 
van, de előfordulhat, hogy több osztály is osztozik ugyan- 
azon a várakozási soron. A sorkezelő megoldásoknál az 
adott osztályhoz tartozó házirend összetevők általában 
eldobják a megadott határértéken túli csomagokat 

(lásd: , Policing and Shaping Overview"). 

A szűrők a sorkezelő elv által alkalmazott szabályokat adják 
meg. A sorkezelő elv ezen szabályok alapján dönti el, hogy 
melyik osztályhoz kell rendelnie a bejövő csomagokat. 
Minden szűrőnek megadott fontossága, prioritása van. 

A szűrők fontosságuk szerint növekvő sorrendbe vannak 
rendezve. Amikor egy sorkezelő elv kap egy csomagot sor- 
ba állításra, akkor megpróbálja egyeztetni azt a megadott 
szűrők valamelyikével. Az egyezés keresése a lista szűrői- 
nek megvizsgálásával történik, kezdve a legnagyobb fon- 
tosságúval. Minden osztályhoz vagy sorkezelő elvhez egy 
vagy több szűrő tartozhat. 

A házirendkezelő összetevők biztosítják, hogy a forgalom 
nagysága ne haladja meg a megadott sávszélességet. A há- 
zirendkezelő döntések a szűrőkön és az osztály alapon 
megadott szabályokon alapulnak. A Linux forgalomszabá- 
lyozó alrendszerének összetevői között fennálló kapcsolato- 
kat a 2. ábra tartalmazza. 


ATC segédprogram és a HTB definíciók 

A TC egy felhasználói program, segítségével várakozási 
sorokat, osztályokat és szűrőket lehet létrehozni, illetve 
hozzá lehet ezeket rendelni a megfelelő kimenő felülethez 
(lásd: , tc-Linux O0S control tool" a források között). A szű- 
rőket az irányítótábla, uw32 osztályozók és TOS osztályozók 
alapján lehet összeállítani. A program netlink foglalatokon 
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1. ábra A rendszermag azt követően hozza meg forgalomszabályozási 
döntéseit, hogy a csomag bekerült a küldési várakozási sorba 


2. ábra A Linux forgalomszabályzó alrendszerében sorkezelő elveket, 
osztályokat, szűrőket és házirendkezelést találunk 
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3. ábra Az 1. tesztmodell összeállítása 


keresztül tartja a kapcsolatot a rendszermag hálózatkezelő 
alrendszerének eljárásaival. Az 1. táblázatban a három fő 
műveletet és a megfelelő TC parancsokat foglaltam össze. 
A TC használatáról a HTB Linux Oueuing Discipline User 
Guide útmutató tartalmaz részletesebb tájékoztatást. 

A HTB használata az egyik mód arra, hogy kézben tart- 
suk az egyes összeköttetések kimenő sávszélességének 
használatát. 


1. táblázat A TC segédprogrammal elvégezhető műveletek 
és a megfelelő parancsok 





TC művelet Parancs 

te gdisc Sorkezelő elv létrehozása 
te filter Szúrő létrehozása 

te class Osztály létrehozása 


A HTB használatához azt osztályként és a sorkezelési 

elv típusaként kell megadni. A HTB a forgalmat a TBF 
algoritmus segítségével alakítja, mely független az alsóbb 
réteg sávszélességétől. Kizárólag a gyökér sorkezelő elvet 
szabad HTB típusként megadni, az összes többi osztály- 
példány a FIFO sort (alapértelmezett) használja. A sorkeze- 
lő folyamat mindig a gyökér szinten indul, majd a szabá- 
lyok alapján dönti el, hogy melyik osztálynak kell meg- 
kapnia az adatokat. Az osztályfa bejárása egészen addig 
folytatódik, míg egyező levélosztályt nem sikerül találni 
(lásd: , Hierarchical Token Bucket Theory"). 


Tesztelés 

A HTB pontosságát és teljesítményét a következő hálózati 
készülékek segítségével próbáltuk ki: egy darab Ixia 400 
forgalomkeltő készülék, egy darab 10/100 Mbps Ethernet 
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4. ábra Az 2. tesztmodell összeállítása 


terhelő modullal (LM100T.X3), továbbá egy darab Pentium 4 
PC (1 GB RAM, 70 GB-os merevlemez), ezen a Linux rend- 
szermag 2.6.5-ös változata futott. Két próbamodellt tervez- 
tünk, egyet a házirendkezelés pontosságának, a másikat 

a sávszélesség megosztásának ellenőrzésére. 

Az első modellt (3. ábra) meghatározott osztály házirend- 
kezelési pontosságának ellenőrzésére használtuk. Az Ixia 1- 
es kapuján keltett forgalom egy vagy több folyamot alko- 
tott, célállomása a 192.168.10.200 IP-cím volt. A linuxos gép 
a csomagokat egy statikus útvonallal az eth0 felületre irá- 
nyította, majd visszaküldte őket az Ixia 2-es kapujára. 

A forgalomszabályozási előírásokat az eth0 felületre lép- 
tettük életbe. Az elemzéseket teljes egészében az Ixia 2-es 
kapuján kapott forgalom alapján végeztük. 

A második modellt (4. ábra) annak vizsgálatára hasz- 
náltuk, hogy két, azonos osztályba tartozó adatfolyam 
sávszélességének megosztása hogyan történik. Ebben 

az esetben további két Ixia kaput vettünk igénybe 

az adatok küldésére. 

Az Ixia 1., 2. és 3. kapuja — egy-egy adatfolyamot használ- 
va — egyaránt mesterségesen keltett forgalmat továbbított 

a 192.168.10.200-as IP-címre. A linuxos gép ezeket a csoma- 
gokat egy statikus útvonal alapján az eth0 felületre irányí- 
totta, majd visszaküldte őket az Ixia 2-es kapujára. A forga- 
lomszabályozási szabályok ebben az esetben is az eth0O felü- 
letre vonatkoztak. Minden elemzést az Ixia 2-es kapujára 
beérkezett forgalom alapján végeztünk. 


Az Ixia készülék beállításai és korlátai 

A küldő kapuk minden próbánál összefüggő csomaglökete- 
ket küldtek, megadott sávszélességgel. Az Ixia 10/100 Mbps 
sebességű Ethernet (LM100TX3 modellszámú) terhelő mo- 
dulja négy különböző kapuval rendelkezik, ezek mindegyi- 
ke legfeljebb 100 Mbps sebességű küldésre képes. Az [ria 
terhelőmodulja képes volt ugyan arra, hogy egy-egy kapun 
több adatfolyamot állítson elő, de nem tudta összekeverni 
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egymással az adatfolyamokat, és egyszerre 
csak egy adatfolyamot szolgáltatott. A korlá- 
tozás oka, hogy ütemezője körbeforgó elven 
működik. Először elküldi az X adatfolyam 
egy bájtlöketét, majd továbblép a következő 
adatfolyamra, és az Y adatfolyamon belül is 
küld egy löketet. 

Ha egy adatfolyamból meghatározott sávszé- 
lességet akarunk előállítani, mely ráadásul 
az adott kapuhoz hozzárendelt adatfolyam- 
csoport tagja, akkor finomhangolnunk kell 
az Ixia bizonyos beállításait. Ezek a beállítások 
— illetve szerepük — következők: 


Adatfolyam 


e — Burst (löket): az egyes folyamokban a következő 
folyamra való továbblépés előtt elküldött csomagok 
száma 

e Packet size (csomagméret): a folyamot alkotó egyes 
csomagok mérete 

e — Total bandwidth (teljes sávszélesség): az összes adatfo- 
lyam által felhasznált sávszélesség 


Az Ixia beállításait a 2. táblázatban foglaltuk össze. 

A cél az volt, hogy meghatározzuk, mi az a löketméret, 
amelynél az egyes adatfolyamokhoz kívánt sávszélessé- 
get el tudjuk érni. Mivel mindhárom adatfolyam ugyan- 
azt a fizikai vonalat használta, az adatok továbbításának 
módja az 5. ábrán láthatóhoz volt hasonló. 

A beállítások közötti összefüggéseket az alábbi egyenle- 
tekkel írhatjuk le: 


Tc — Sum( Bs- " 8 " Ps-i ) / Tb 





Mesterségesen Löketméret 


keltett sávszélesség 


Csomagméret 


Beállítás Jelentés 








N-c — 1/Tc 
Bn-i — Nc " Pss." 8" Bs-i 


Az egyenletekben használt változók jelentését a 3. táblázat 
tartalmazza. 





Idő 





Feltételezve, hogy a csomagméret minden adatfolyam eseté- 
ben azonos, ahogy a példában is, csak a löketméret meghatá- 
rozása marad hátra. 

Mivel minden adatfolyam ugyanazon a sávszélességen 


5. ábra Az adatok áramlása az átviteli vonalon 
az lxia készülék és a tesztelt Linux rendszer között 





osztozik, az elvárt löketértékeket az elvárt sávszélességek 
közötti arányok vizsgálatával kaphatjuk meg, a B7 — B" 
egyenlet alapján. Ez az érték meglehetősen nagy is lehet, 
szükség esetén osztásokkal hozhatjuk kezelhetőbb for- 
mára. Ha különböző csomagméreteket akarunk hozzáren- 
delni az egyes adatfolyamokhoz, akkor a löketméretek 





Sebesség — 30Mbit/s 
Korlát — 30Mbit/s 





szükség szerint ismételt módosításával kaphatjuk meg 
az egyes adatfolyamokban a kívánt sávszélességeket. 
Táblázatkezelő program segítségével egyszerűbben, 
könnyebben végezhetjük el a több sávszélességre is 
kiterjedő számításokat. . 


Tesztek és eredmények 
A HTB beállításainak megadásakor a következő tc class . 
parancsokat használtuk az elvárt eredmények eléréséhez: 


e rate — adott osztály legfeljebb ennyi sávszélességet . 
használhat el úgy, hogy nem más osztályoktól veszi 
azt kölcsön 
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6. ábra 1. teszt — egy-egy be- és kimenő 
adatfolyam 


ceiling — adott osztály legfeljebb ennyi sávszélességet 
használhat el; így szabályozható, hogy az osztály mek- 
kora sávszélességet vehet kölcsön másoktól 

burst — maximális sebességgel legfeljebb ennyi adatot 
lehet elküldeni, mielőtt a következő osztály kiszolgálá- 
sára lépnénk tovább 

cburst — az átviteli közeg sebességével legfeljebb ennyi 
adatot lehet elküldeni, mielőtt a következő osztály ki- 
szolgálására lépnénk tovább 














4. táblázat Az 7. tesztmodellel kapott eredmények 








Burst Cburst Csomagméret Bejövő sávszélesség Kimenő sávszélesség 

(bájt) (bájt) (bájt) (Mbps) (Mbps) 

Alapértelmezett Alapértelmezett 128 40 9890 

Alapértelmezett Alapértelmezett 64 40 z 

Alapértelmezett Alapértelmezett 64 32 (Max) 2952 

íl5ak l6ae 64 32 (Max) 30 

(DK 15k 512 SZE S0GSZ0 2578 

15 (51 1500 0472 (áj 1010) tér 740) 29 

18k 18k 64 32 (Max) DOT 

18k 18k 5112 SZE DOEZO 30,26 

18k 18k 1500 SZzEr50á 70 aaa 
5. táblázat A Burst/Cburst és Rate értékek közötti kapcsolat 

Burst Cburst Csomagméret Bejövő sávszélesség Kimenő sávszélesség Hozzárendelt sebesség 

(bájt) (bájt) (bájt) (Mbps) (Mbps) (Mbps) 

9k gk 64 8 145 5 

gk 9k b2 32 da 149 

gi gi 1500 32 15.28 illo 

48k 48k 64 02 8.96 8 

48k 48k SZ éz 8,176 8 

48k 48k 1500 82 8 8 

Si 3k 64 32 117745 5 

SI sik oz 92 15.12 6 

8.1 811 1500 8 a 28 15 





Az internetes világ forgalmának túlnyomó része TCP alapú, 
ezért a próbák során is a datagramokra jellemző — 64 bájtos 

(ICP Ack), 512 bájtos (FTP) és 1500 bájtos — csomagmérete- 

ket választottunk. 


Az első tesztmodell 
A 4. táblázatban foglalt eredmények alapján a következőket 
jelenthetjük ki: 


e Egy linuxos gép 64 bájtos csomagokból álló, összefüggő 
adatfolyamok esetén körülbelül 34 Mbps sebességgel 
képes továbbítani (egyik interfészen fogadni, a másikon 
küldeni) a forgalmat. 

e A legjobb átlagos szabályzási pontosságot 18 k/ 18 k 
burst/cburst érték mellett kapjuk. 

e A löket (burst) érték és az elvárt sebességérték 
között lineáris kapcsolat van, ez a tesztek során egyér- 
telművé válik. 

e A rKkimenő felületre erőltetett sávszélesség nem befolyá- 
solja az eredmények pontosságát. 
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A 7. ábra a csomagméret és a kimenő sávszélesség közötti, 
különféle csomagméretekkel elvégzett tesztek során kapott 
eredmények alapján megállapított kapcsolatot szemlélteti. 
A 4. táblázatban és a 7. ábrán szereplő eredményekből két 
tanulságot vonhatunk le: egyrészt az átvitel szabályzásának 
pontosságát a cburst/burst értékek módosításával lehet be- 
folyásolni, másrészt a pontossági sávszélesség-tartomány 2 
Mbps széles, amennyiben a csomagméret 64 és 1500 bájt kö- 
zötti. Azt, hogy a burst/cbursts értékek és az átviteli sávszé- 
lesség (rate) között lineáris összefüggés van, többféle burst 
és cburst érték vizsgálatával igazoltuk. Az 5. táblázat a pró- 
bák során kapott adatminták fontosabbjait tartalmazza. 

A kiindulási érték 18 k / 18 k volt. A burst/cburst értéke- 
ket a cburst/burst (Kb) — 18/(Z2OM/hozzárendelt sebesség) 
képlet alapján kaptuk. Az 5. táblázatban szereplő eredmé- 
nyek szerint a cburst/burst értékeket dinamikusan lehet 
megadni a sebességértékhez, mint amikor lineáris kapcso- 
latot feltételezünk. 

A 6. táblázat az egyszintű öröklődésre mutat példát. A 2. és 
a 3. osztály örökli az 1. osztály sebességkorlátját (30 Mbps). 
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cburst/ burst 17k/17k cburst/ burst 18k/18k 
Sebesség (Mbit/s) Sebesség ( Mbit/s) 
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64 HON.2N0 ZŐD a eres 1500 64. 100 200 300 ..ssssrzasseréssínsssa 1500 
Csomagméret Csomagméret 





Sebesség — 30Mbit/s 
Korlát — 30Mbit/s 






Sebesség — 2Mbit/s 
Korlát — 30Mbit/s 


Sebesség — 28Mbit/s 
Korlát — 30Mbit/s 











7. ábra A csomagméret és a kimenő sávszélesség kapcsolatának 
grafikus elemzése 


8. ábra 2. teszt— három bejövő és egy kimenő adatfolyam 


6. táblázat A 2. teszt eredményei 





Adatfolyam Burst Cburst Csomagméret 
(bájt) (bájt) (bájt) 

1 1748 17718 64 

2 ira 17712 mil 

3 ÁK 1k DÍ 

Összes 18k 18k Z 


Bejövő sávszélesség Kimenő sávszélesség Osztály 
(Mbps) (Mbps) 

115 iz 3 

20 Zé 8 

4 270 2 

eg 9188 — 


7. táblázat A 3. teszt eredményei 





Adatfolyam Burst Cburst Csomagméret 
(bájt) (bájt) (bájt) 

1 lk 1k S 

2 6k 6k 6 

3 31 SA 64 

4 1/0874 7581K 02 

Összes 18k 18k S 


Ennél a tesztnél a gyermekosztályok felső sebességkorlát- 
ja megegyezik a szülő korlátjával, vagyis a 2. és a 3. osz- 
tály legfeljebb 30 Mbps sávszélességet vehet kölcsön. 

A többi osztályhoz tartozó cburst/burst értékeket lineáris 
összefüggést feltételezve, az elvárt sávszélességek alapján 
számítottuk ki. 

A 6. táblázat azt szemlélteti, hogy egyszintű öröklés- 
nél hogyan jellemezhető a lineáris összefüggés. A teszt 
során a bejövő adatfolyam 39 Mbps sávszélességű, 
folyamatos forgalmat ad, a teljes kimenő sávszélesség 
pedig 31,8 Mbps. 

A 7. táblázat a kétszintű öröklést szemlélteti. A 2. és 

a 3. osztály örökli az 1. osztály sebességkorlátját 

(30 Mbps). A 4., az 5. és a 6. osztályok a 3. osztály sebes- 
ségkorlátját öröklik (28 Mbps), és saját sebességhatáraik 
szerint osztoznak rajta. A tesztben a gyermekosztályok 
felső sebességkorlátja megegyezik a szülő korlátjával, 
vagyis a 4., az 5. és a 6. osztály legfeljebb 28 Mbps 
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Bejövő sávszélesség Kimenő sávszélesség Osztály 
(Mbps) (Mbps) 

5 2,04 2 

ú5 (ESZE 4 

10 SI6/ b 

20 16.02 6 

50 3205 — 


sávszélességet vehet kölcsön. A többi osztályhoz tartozó 
cburst/burst értékek kiszámítása lineáris összefüggést fel- 
tételezve, az elvárt sávszélességek alapján történt. 

A 7. táblázatban foglalt eredmények alapján megállapíthat- 
juk, hogy a lineáris kapcsolat kétszintű öröklésnél is fenn- 
áll. A teszt során a bejövő kapu 50 Mbps sávszélességű, 
folyamatos forgalmat fogad, a teljes kimenő sávszélesség 
pedig 32,05 Mbps. 


A második tesztmodell 

Ahogy a 8. ábrán is követhető, a sávszélesség egyenlően 
oszlik meg az adatfolyamok között, amennyiben ezek azo- 
nos számú bájtot küldenek el, illetve azonos osztályhoz tar- 
toznak. Egy másik kísérlet, amelynél az 1. adatfolyam bejö- 
vő sávszélessége nagyobb volt, mint a 2. és a 3. adatfolya- 
mé, kimutatta, hogy az 1. adatfolyamnak a kimenő sávszé- 
lessége is nagyobb volt, mint a 2. és a 3. adatfolyamé. Az 
eredményekből arra következtethetünk, hogy ha több ada- 
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Adatfolyam Burst Cburst Csomagméret Bejövő sávszélesség Kimenő sávszélesség Osztály 
(bájt) (bájt) (bájt) (Mbps) (Mbps) 








küldeni) a forgalmat. A korlát azért jelentkezik, mert az 
Ethernet illesztőprogram által fogadott vagy elküldött 
csomagok mindegyike egy megszakítást vált ki. A meg- 
szakítások kezelése processzoridőt igényel, ami értelem- 
szerűen akadályozza a rendszer egyéb folyamatainak 
működését. 

e Ha a forgalmat 30 Mbps sebességre állítjuk, 18 k/ 18 k 
cburst/burst érték mellett kapjuk a legjobb átlagos pon- 
tosságot. 

Sebesség — 13Mbit/s e A löket (burst) érték és az elvárt sebességérték között 

Korlátj— 28Mbit/s Korlát — 28Mbit/s ú j 

lineáris kapcsolat van. A 30 Mbps sebességhez tartozó 
éz) cburst/burst értékek megfelelő kiindulási alapot szolgál- 
tatnak a más sebességekhez tartozó burst értékek meg- 
határozásához. 

9. ábra 3. teszt — négy bejövő és egy kimenő adatfolyam e Az átvitel pontosságát a cburst/burst értékek módosítá- 

sával lehet szabályozni. A pontos szabályozás sávszéles- 

Sebesség — 30Mbit/s ség-tartománya 64-1500 bájt közötti méretű csomagok- 
Korlát — 30Mbit/s nál körülbelül 2 Mbps. 

e A sávszélesség egyenlően oszlik meg az adatfolyamok 
között, amennyiben azok azonos számú bájtot küldenek 
el, illetve azonos osztályhoz tartoznak. 
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Sebesség — 2Mbit/s 
Korlát — 30Mbit/s 


Sebesség — 28Mbit/s 
Korlát — 30Mbit/s 


Sebesség — 10Mbit/s 
Korlát — 28Mbit/s 


Sebességj— 5Mbit/s 




















Sebesség — 2Mbit/s 
Korlát — 2Mbit/s 


Sebesség — 28Mbit/s Linux Journal 2005. március, 131. szám 
Korlát — 28Mbit/s 
Yaron Beníta az izraeli Jeruzsálemben született, jelenleg San 
Franciscoban, Kaliforniában él. A Prediwave CMTS szoftver- 
igazgatója, munkája során elsősorban hálózatokkal és be- 
ágyazott rendszerekkel foglalkozik. Nős, van egy hat hóna- 
10. ábra 1. teszt — három bejövő, egy kimenő adatfolyam pos, gyönyörű kislánya. A varonboprediwave.com vagy az 
ybenitagyahoo.com címen érhető el. 











tot küldünk egy meghatározott adatfolyamban, akkor az az 
azonos osztályba tartozó egyéb folyamokhoz képest több 
csomag továbbítására lesz képes. 








Osszefoglalás 

Az ismertetett kísérletek elvégzése az egyik lehetőség 5 snafu.freedom.org/linux2.2/iproute-notes.html 
a HTB pontosságának és teljesítményének vizsgálatára. 

Bár a folyamatosan érkező, adott forgalmat jelentő löketek 5 teng.sourceforge.net 


nem feltétlenül jellemzőek a valós életbeli adatforgalomra, 
vizsgálatukkal mégis megkaphatjuk a kiindulási pontokat 
a HTB osztályok és jellemzőik megadásához. 

A kísérletek eredményeit a következő kijelentésekkel össze- 
gezhetjük: 


2 luxik.cdi.cz/ devik/gos/htb/manual/userg.htm 
5 luxik.cdi.cz/- devik/gos/htb/manual/theory.htm 


2 www.cisco.com 


e Egy linuxos gép 64 bájtos csomagokból álló, összefüggő 2 www.rns-nis.co.yu/—mpszllinux-tc.html 
adatfolyamok esetén körülbelül 34 Mbps sebességgel 
képes továbbítani (egyik interfészen fogadni, a másikon 
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A 2.6-os Linux rendszermag valós idejű 
és teljesítmény fejlesztései 


A Linux rendszermag érzékenységének és valós idejű teljesítményének 
fejlesztése a jövőben még kedvezőbb fordulatot vehet. 


Linux rendszermag, minden Linux terjesztés belső 
A magja, folyamatosan fejlődik. Új módszereket 

olvaszt magába, növeli a teljesítményét, a skáláz- 
hatóságát és használhatóságát. Bár minden rendszermag 
kiadás újabb alkatrészeket támogat, a nagyobb rendszermag 
verzióváltások általában komolyabb változásokat jeleznek 
a rendszermag felépítésében. Ilyen a 2.6-os Linux rendszer- 
mag is. A 2.6-os Linux rendszermag számos változása jelen- 
tősen befolyásolja a Linux rendszermag teljesítményét az 
alkalmazott alkatrészektől függetlenül, valamennyi Linux 
rendszeren. A 2.6-os rendszermag komoly változásokat hoz 
a rendszer érzékenységében, jelentősen csökkenti a folya- 
mat és szál-vonatkozású rendszermag többletmunkát vala- 
mint a feladat ütemezése és végrehajtása között eltelt időt. 
Ma már szinte az ipar valamennyi nagyobb Linux terjeszté- 
se a 2003 végén kiadott 2.6 rendszermagon alapul az asztali 
gépektől a beágyazott rendszerekig. A rendszermag és 
rendszerteljesítmény rendkívül fontos az olyan koncentrált 
piacokon mint a beágyazott gépek területe, ahol a magas 
prioritású folyamatoknak gyakran valós időben kell végre- 
hajtódniuk anélkül, hogy a rendszer félbeszakítaná őket. 
Ugyanakkor a rendszer teljesítménye és átviteli képessége 
legalább ilyen fontos a linuxos asztali gépek, és az egyre 
sikeresebb Linux vállalati kiszolgálópiacon. 
Cikkünkben a valós idejű és rendszerteljesítményt befolyáso- 
ló paraméterek természetével foglalkozunk, kiemelve a 2.6 
rendszermagjba teljesítmény és érzékenység terén bevezetett 
legfontosabb újításokat. A teljesítmény és az érzékenység to- 
vábbra is fontos fejlesztési terület maradt, cikkünkben a Linux 
teljesítményének és érzékenységének növelését valamint 
a valós idejű működést célzó néhány aktuális megoldással 
foglalkozunk. A különféle Linux rendszermagok és projektek 
belső, illetve folyamat végrehajtó teljesítményét grafikus telje- 
sítményteszteken jelenítjük meg ahonnan leolvasható, ho- 
gyan viselkednek az egyes rendszermagváltozatok különféle 
terhelési körülmények között. 


Lappangás, preemptiv képességek és teljesítmény 
Magasabb teljesítményt gyakorta további és erősebb alkat- 
részek felhasználásával lehet elérni, azaz komolyabb 
processzort, nagyobb memóriamennyiséget alkalmazunk. 
Bár ez egy adatközpontban megfelelő megoldásnak bizo- 
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nyulhat, jónéhány területen ez nem jelent kielégítő megol- 
dást. A beágyazott Linux rendszerek például kifejezetten 
érzékenyek a felhasznált alkatrészek árára. Ezen kívül ha 
teljesítmény és végrehajtási gondokat memóriavásárlással 
és más alkatrészekkel próbáljuk megoldani mindössze ideig- 
lenesen elfedjük a problémát. Ahogy a programok igénye 
növekszik, idővel átlépi a bővített erőforrások határát is, 

így a probléma ismét a felszínre kerül. 

Ezért igen fontos hogy a Linux rendszerekben alkatrész- 
kerülő módon, a belső rendszer mag javításával érjünk 

el teljesítménynövekedést. Cikkünk az ilyen típusú Linux 
teljesítnénymérésekre koncentrál. 

A valós idejű rendszerek azon a rendszerek közé tartoznak, 
ahol a rendszer helyes működése nem csak a kívánt művelet 
végrehajtásának sebességétől függ, hanem egy bizonyos idő- 
zítési kritériumtól is. Kétféle valós idejű rendszer létezik: 

a lágy és a kemény. A kemény valós idejű rendszerek eseté- 
ben a kritikus folyamatoknak egy adott időszeletben kell le- 
futniuk vagy a teljes rendszer hibásnak tekinthető. Klasszikus 
példa ilyen rendszerre a számítógép vezérlésű autógyújtásve- 
zérlő rendszer — ha a hengerek nem pontosan a jó időben 
kapnak gyújtást, az autó nem fog működni. A lágy valósidejű 
a teljes rendszer összeomlása nélkül; a rendszer helyre tud 
állni az ideiglenes érzékenység csökkenés után. 

Mindkét fajta valós idejű rendszer először a magas prioritá- 
sú feladatokat hajtja végre egy ismert előrejelezhető idősze- 
leten belül. Ez annyit jelent, hogy az operációs rendszer 
nem végezhet aránytalan többletmunkát a feladat üteme- 
zés, végrehajtás és kezelés során. Ha a folyamatokkal 
kapcsolatos többletmunka jelentős mértékben növekszik 

a feladatok számának növekedésével, akkor a teljes rend- 
szerteljesítmény leromlik ahogy egyre több idő szükséges 
az ütemezés, váltás és újraütemezés elvégzéséhez. A kiszá- 
míthatóság a valós idejű operációs rendszerek egyik legfon- 
tosabb jellemzője. Ha nem tudjuk kiszámítani a rendszer 
teljesítményigényét egy tetszőleges időpillanatban, nem 
tudjuk biztosítani, hogy az adott folyamat szükség esetén 
előre látható lappangással indul el vagy indul újra, illetve 
hogy az előírt időszeletben befejeződik-e. 

A 2.6-os Linux rendszermagban új típusú ütemező jelent 
meg, amelynek végrehajtási ideje nem függ az ütemezett 
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1. ábra A dobozos Fedora Core rendszermag remegési értékei 


feladatok számától. Ez a megoldás O(1) ütemezőként ismert 
a nagy-O algorimus jelölési rendszerben, ahol az O az an- 
gol Order szó rövidítése, a zárójeles szám pedig a leg- 
rosszabb teljesítmény felső határa az algoritmusban résztve- 
vő elemek függvényében. Az O(N) tehát annyit tesz, hogy 
az algoritmus hatékonysága az elemek számától függ, az 
O(1) jelentése pedig, hogy az algoritmus, azaz jelen esetben 
az ütemező futásigénye minden esetben azonos, azaz füg- 
getlen a résztvevő elemek számától. 

Az operációs rendszernek kiadott feladatvégrehajtási utasí- 
tás és a feladat tényleges elindulása között eltelt időt lap- 
pangásnak nevezzük. A folyamatvégrehajtás nyilvánvaló 
módon függ az adott feladat fontossági szintjétől, de azo- 
nos fontosságot feltételezve, azt az időt amelyet az operáci- 
ós rendszer a feladat ütemezésével és futtatás megindításá- 
val tölt, a rendszerütemező többletmunkája és a rendszer 
által végzett egyéb tevékenységek határozzák meg. Amikor 
feladatot ütemezünk a rendszer futtatási sorába helyezve, 
a rendszer megvizsgálja, hogy a folyamat magasabb priori- 
tású-e mint az éppen futó folyamat prioritási szintje. 

Ha igen, a rendszermag megszakítja az éppen futó folya- 
matot és átvált az új folyamat környezetére. A rendszer- 
magban az éppen futó folyamat megszakítását és a környe- 
zetváltást nevezzük preempciónak. 

Sajnos, a rendszermag nem mindig használhatja 

a preemptivitást. Az operációs rendszer magja gyakran 
igényel kizárólagos erőforrás és belső adatszerkezet elérést, 
hogy fenntarthassa saját belső szerkezetének sérülésmen- 
tességét. A Linux rendszermag régebbi verzióiban az erő- 
forrásokhoz való kizárólagos hozzáférést gyakran forgózá- 
rakkal biztosították. Ez ennyit jelentett, hogy a rendszer- 
mag egy rövid ciklusban lépkedett, amíg az adott erőforrás 
elérhetővé nem vált, vagy amíg használatban volt, ezzel 
persze megnövelve minden más feladat lappangását amíg 
a rendszermag be nem fejezte a feladatát. 

A rendszermag preemptivitásának felbontása folyamatosan 
fejlődött az elmúlt nagyobb rendszermag verziókban. Például 
a beágyazott Linux és eszköz gyártótó TimeSys-től származó 
GPL 2.4 Linux rendszermag, egy korábbi alacsony lappangá- 
sú ütemezőt és teljesen preemptív rendszermagot tartalma- 
zott. A 2.4-es Linux rendszermag sorozatban, Novel[/Ximian- 
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tól Robert Love kiadott egy jól ismert rendszermag foltot 
amely magasabb preemptivitást biztosított és amelyet a ha- 
gyományos rendszermag forrásra is alkalmazni lehetett. Más 
foltok, mint például az 1995 óta belső rendszermagíró Molnár 
Ingo alacsony lappangási foltja, tovább fokozták e folt teljesít- 
ményét és csökkentették a rendszermag lappangási idejét. 

A TimeSys termékének és az említett foltok kulcselképzelése 
az volt, hogy a forgózárakat mutexekkel (mutual exclusion 
mechanism, azaz kölcsönös eléréskizárás) kell helyettesíteni 
ahol csak lehet. Ezek ugyanis anélkül biztosították a rendszer- 
mag erőforrás és integritás biztonságát, hogy a rendszerma- 
got leállították és várakozásra kényszerítették volna. Ezen 
úttörő foltok által használt megoldások ma már a 2.6 Linux 
rendszermag szerves részét képezik. 


Valós idejű megoldások Linux alatt 

Három valós idejű linuxos megoldás létezik jelenleg: az RTAI 
Projekt által alkalmazott kettős rendszermag modell, amelyet 
beágyazott Linux gyártók, például az FSMLabs termékeiben 
alkalmaznak; egy beágyazott Linux gyártó, a MontaVista 
szárnyai alatt fejlődő Real-time Linux Projekt; valamint a sza- 
munka, amelyet Molnár Ingó és más fejlesztők neve fémjelez, 
s amelyet nyíltan vitatnak meg a Linux rendszermag levele- 
zőlistán, és amelyre a MontaVista Projekt is épít. Ezeken az 
alap rendszermag modelleken felül más kiegészítő projektek, 
például a robosztus mutexek és a nagy felbontású időzítők is 
jelentős mértékben hozzájárultak a valósidejű alkalmazások 
teljes körű támogatásának fejlődéséhez Linux alatt. 

A valós idejű kettős rendszermag elgondolás igen érdekes 
megközelítése a Linux alatti valós idejű alkalmazáskezelés 
problémakörének. Ebben az elképzelésben a rendszer tulaj- 
donképpen egy apró, nem Linux valósidejű rendszermagot 
futtat, amely viszont a Linuxot futtatja a lehető legalacso- 
nyabb prioritási szinten. A valósidejű alkalmazások, ame- 
lyeket kifejezetten ehhez a nem-linuxos rendszermaghoz 
írtak a hozzá tartozó valósidejű csatolófelület felhasználásá- 
val, ebben a rendszermagban hajtódnak végre, de maga- 
sabb szinten mint a Linux vagy bármely Linux alkalmazás. 
Ugyanakkor képesek adatokat cserélni a Linux alkalmazá- 
sokkal. Igaz, műszakilag nagyon érdekes elgondolás, 
amellyel valósidejű alkalmazásokat futtathatunk Linux 
rendszer mellett, azonban teljességben kikerüli az általános 
Linux rendszermag preemptivitás és teljesítmény fokozási 
problémákat. Éppen ezért a Linux mag fejlődésének szem- 
pontjából nem is olyan érdekes. 

A MontavVista Projektre, azaz a másik valós idejű Linux 
megoldásra igen nagy hatással volt Molnár Ingo és más 
rendszermagfejlesztők által végzett már meglévő munka, 
azonban tartalmaz néhány egyéb prototípus foltot, amelyek 
kizárólag a MontaVista weblapján érhetőek el. A jelenlegi 
foltok itt a 2.6.9-es Linux rendszermaghoz valók (rc4). Ezért 
aztán nem igazán alkalmazhatók probléma mentesen a hi- 
vatalos Linux rendszermag kiadásokra, amelyek írásunk 
születésekor már a 2.6.1-es verzió felé járnak. Így aztán 

e projektből származó eredményeket nem tudtuk meg- 
mutatni ebben a cikkben. 

Molnár Ingó az O(1) Linux ütemező atyja és más fejlesztők 
munkája az ütemezőn és a preemptivitási képességeken 
igen komoly lendülettel haladnak. Miközben kibővítik 
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2. ábra Remegési eredmények egyszerű 2.6.11-rc3 Rendszermaggal 


a Linux rendszermag lehetőségeit, naprakész foltokat nyúj- 
tanak, amelyek a hatékonyabbá varázsolják a rendszerüte- 
mezést, csökkentik a lappangási időt és tovább növelik 

a preemptivitást. 

Ezeket a foltokat nagy figyelemmel kísérik számtalan cso- 
port és szervezet fejlesztői, beleértve a Raytheont, olyan be- 
ágyazott Linux fejlesztőket mint a TimeSys valamint a Linux 
audió közösség. A foltok megnövelik a rendszerérzékenysé- 
get és minimálisra csökkentik a megszakítások hatását, két 
részre osztva a megszakításkezelőket: egy közvetlen alkat- 
rész válaszra és egy ütemezhető megszakítás feldolgozó 
szakaszra. Mint a nevük is mutatja a megszakítások olyan 
kérelmek, amelyek azonnali figyelmet igényelnek a rend- 
szertől. Az ütemezhető megszakítás kezelési megoldás, 
vagy ismertebb nevén soft IRO, a lehető legkisebbre csök- 
kenti az általános rendszer reakcióidő és teljesítmény. 

A következő rész ábrái különféle sima rendszermagok telje- 
sítményét érik össze Molnár Ingó és mások által készített 
ütemezési, preemptivitási foltokkal javított változatok 
képességeivel. Ezek a foltok naprakészek és teljes Linux 
rendszermag fejlesztéseket tartalmaznak melyek közvetlen 
előnyöket nyújtanak bármely Linux felhasználónak aki 
projektjébe szeretné építeni őket. 


Teljesítnénymérés 

2002-ben, a Linux Journal weblapon megjelentet egy cikk 
Andrew Webber tollából , Realfeel Test of the Preemptible 
Kernel Patch" címmel. Ez a cikk Mark Hahn Realfeel nevű 
nyílt teljesítménymérő programját használta , hogy össze- 
hasonlítsa a preemption és érzékenység értékeket az eredeti 
Linux 2.4-es és Robert Love preemptivitási foltjával javított 
rendszermagot. A Realfeel periodikusan megszakításokat 
hoz létre, majd a számítógép mért válaszidejét összehason- 
lítja a rendszer optimális válasz idejével. A megszakításké- 
rés kiadása és annak kezelése közt eltelt idő a lappangás, 
az előrejelzett és a tényleges lappangás között eltelt idő 

a remegés (jitter). Ezt a remegés értéket gyakran használják 
a rendszer válaszidejének mérésére és összehasonlítására. 
Cikkünk ugyanazt a teljesítnénymérő programot használja 
mint amelyet Webber cikkében megismerhettünk, ám mérés 
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3. ábra Remegési eredmények valós-idejű/Preemptív folttal ellátott 
2.6.11-rc3 Rendszermag esetében 


közben lényegesen nagyobb terhelést tettünk a gépre. Valós 
idejű operációs rendszerek tesztelése során gyakran alkal- 
mazzák ezt a módszert, hiszen még a nem valós idejű rend- 
szerek is alacsony lappangást mutathatnak amikor terhelés 
nélkül vagy alacsony terhelés mellett működnek. A követke- 
ző fejezet rajzai az eredményeket is kicsit másképp ábrázol- 
ják, hogy könnyebb legyen elképzelni és összehasonlítani a 
különféle Linux rendszerek lappangási idejének különbségeit. 


Mérési eredmények 

A fejezeteben található eredmények egy közepes teljesítmé- 
nyű Pentium osztályú rendszeren készültek, amelyet egyet- 
len 1.7GHz AMD Athlon processzor hajtott meg, 512MB 
rendszermemória mellett. A rendszer GNOME asztalkezelő 
környezetet és Fedora Core 3 Linux terjesztésben szokásos 
rendszerfolyamatokat futtatta, 2004 február 10.-ei legfris- 
sebb foltokkal. A kipróbált rendszerek: eredeti 2.6.10 Linux 
rendszermag, a 2.6.10-1.760 FC3 rendszermag, amelyet 

a Fedora Core 3 frissítéssel érhetünk el, eredeti 2.6.11-rc3 
rendszermag és a 2.6.11-rc3 rendszermag Molnár Ingo 
legújabb valós idejű preemptivitási foltjával. Minden rend- 
szermagot azonos rendszermag beállításállomány mellett 
fordítottuk, eltekintve persze az új rendszermagforrásban 
felbukkanó újabb beállításoktól. 

Az olyan több folyamatos rendszerekben mint a Linux, 

a rendszer soha nem alszik. Bizonyos rendszerfolyamatok, 
például az ütemező, állandóan futnak. Amennyiben grafikus 
felületet használunk (GUTJ) és kezelőfelületeket mint a KDE, 
a GNOME vagy akár az egyszerű X Window rendszer, az ab- 
lakkezelők folyamatosan várják a beérkező eseményeket. Mi- 
vel az igazi preemptivitást és valós idejű teljesítményre vol- 
tunk kíváncsiak, pár alkalmazás elindításával megterheltük 
a rendszert, miközben az egyes teljesítménymérő tesztek 
eredményeit gyűjtöttük. Mint korábban említettük, a rend- 
szer GNOME-ot futtatott négy nyitott xterm mellett — ezek 
közül egyben futott a realfeel teljesítménymérő a másikban 
pedig egy olyan folyamat futott, amely állandóan ls és find 
parancsokat hívogatott a rendszer gyökérpartícióján, végül 

a maradék kettőben külön forráskönyvtárban található Linux 
2.6.x rendszermagok fordultak, clean állapotból. 











Az 1. ábra a Realfeel teljesítménymérő grafikonján ábrázolja 
egy dobozos Fedora Core rendszeren futtatva egy percen ke- 
resztül. A rendszer 2.6.10-1.760 FC3 rendszermagot futtatott, 
amely lényegében egy 2.6.10-es rendszermag néhány Red 
Hat folttal és fejlesztéssel. A pontok a megszakítás kérés és 
kezelés közötti remegést (jitter) ábrázolják. Az X tengely 

a mintaidő 1/60-ad másodpercben. A negatív remegési érté- 
kek olyankor fordulnak elő amikor a rendszer gyorsabban vá- 
laszolt mint az előrejelzett válaszidő. Amint azt az ábrán lát- 
hatjuk, a megszakítási kérelmek legtöbbje a várakozásoknak 
megfelelő idő alatt készült fel, így eredményképpen egy jól 
kivehető sörtét vonalat kapunk az Y tengely 0 értéke körül. 

A 2. ábra ugyanezen rendszer Realfeel programmal mért 
eredményeit mutatja sima 2.6.11rc3 rendszermaggal, amely 
a következő 2.6.11 rendszermag 3. kiadási jelöltje. Azt ered- 
ményeket ismét csak egy perc alatt gyűjtöttük. Amint azt 
az eredményekből láthatjuk, a 2.6.11-rc3 rendszermag jobb 
teljesítményt nyújtott mint az FC3-as rendszermag, sokkal 
több helyen tapasztalhatjuk, hogy a megszakítás kérelem 
és kezelés közötti remegés 0 értékű. 

A 3. ábrán Molnár Ingó valós-idejű/preemtivitás foltjaival 
bővített 2.6.11rc3 rendszermagot használó, de egyébként 
változatlan rendszer eredményeit látjuk Realfeel program- 
mal mérve. Ezeket az eredményeket is egy perc alatt 
gyűjtöttük össze, az előzőekkel azonos terhelésgenerátor 


mellett. Amint azt az eredményekből láthatjuk, a valós- 
idejű/preemptivitás folt esetében lenyűgözően jó remegési 
eredményeket kaptunk, és viszonylag kevés helyen látha- 
tunk eltéréseket a becsült időintervallum értékekhez képest. 


Rendszerünkön mindez nagyobb érzékenységet eredmé- 
nyez, a programfíutás jóval kiszámíthatóbb mint azt egy sima 
FC3 vagy eredeti 2.6.11-rc3 rendszermag esetében várnánk. 


Osszefoglalás 

A 2.6-os Linux rendszermag javított ütemezése, SMP és ská- 
lázási fejlesztései nagyobb teljesítményű Linux rendszereket 
eredményeztek mint bármikor azelőtt. Jobban ki tudják 
használni a rendszererőforrásokat valamint kiszámíthatób- 
ban futtatják a rendszermagot és a felhasználói folyamato- 
kat a rendszer igényei szerint. Léteznek további javítások is, 
ám ezeket jelenleg csak a rendszermag kézi foltozásával 
használhatjuk, vagy olyan gyártótól kell Linux terjesztésün- 
ket beszerezni, mint a TimeSys, amely már beépítette és 
teszteli ezeket a nagyteljesítményű foltokat. 

Kész csoda, hogy egyáltalán létezik ilyen szabad, nyílt for- 
rású rendszermag és robosztus végrehajtási környezet mint 
a GNU/Linux. Most, hogy egyéni fejlesztők mellett már cé- 
gek is fejlesztik teljesítményét, még fényesebb jövőt jósol- 
hatunk neki. Ezek, és a Linux egyéb módosításai felvetik 

és érvéként szolgálhatnak a Linux mint javasolt operációs 
rendszer mellett a beágyazott rendszerek, kiszolgálók 

és asztali gépek területén. 


Linux Journal 2005. június, 134. szám 
A cikk forrása: 5 www.linuxjournal.com/article/8199 


William von Hagen 
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Dinamikus megszakításkérés-kiosztás 


illesztőprogramokhoz 


A megszakítás az az eszköz, amellyel a hardver felhívja magára a szoftver figyelmét. 


Vizsgáljuk meg a működését! 


gy számítógép a vele szemben támasztott elvárások- 
e nak csak akkor tud megfelelni, ha külső eszközökkel 

is képes kapcsolatba lépni. Az eszközök és a pro- 
cesszor közötti kapcsolattartáshoz az átjárót a megszakítások 
biztosítják. A megszakításkérési vonalak eszközökhöz való 
hozzárendelése és a megszakítások kezelésének módja kulcs- 
szerepet játszik az illesztőprogramok fejlesztésében. Mivel 
a megszakításkérési vonalak száma korlátozott, nagyobb szá- 
mú eszközhöz csak a megszakítások megosztásával biztosít- 
hatunk hozzáférést. Ugyanakkor, ha megpróbálunk kiosztani 
egy már használatban lévő megszakítást, a rendszer össze- 
omlik. Írásomban a megszakításokkal és a megszakításkeze- 
léssel kapcsolatos alapismereteket szeretném átadni, vala- 
mint be szeretnék mutatni egy karakteres eszközökhöz hasz- 
nálható megszakításkérés-kiosztó (IRO) megoldást. 
Minden eszköz célja valamilyen hasznos feladat ellátása, és 
ennek teljesítéséhez kapcsolatot kell tartania a processzorral. 
Ha a processzor közölni szeretne valamit az egyik eszközzel, 
akkor a megfelelő eszközvezérlőnek küldi el utasításait. 
Az eszközvezérlő irányítja az eszköz működését. Hasonlóan, 
ha az eszköz válaszolni szeretne a processzornak, mert pél- 
dául a kért adatok készen állnak a beolvasásra, akkor egy 
megszakítás létrehozásával vonja magára a processzor 
figyelmét. A megszakítás egy hardveres, a processzor és 
az eszköz közötti kommunikációt lehetővé tévő megoldás. 
A Linux egészen a 2.6-os változatig nem preemptív műkö- 
désű volt, ami azt jelenti, hogy ha egy folyamat rendszer- 
mag módban fut, és a futtatásra kész folyamatok várólistájá- 
ra felkerül egy nagyobb fontosságú folyamat, akkor a kisebb 
fontosságú folyamattól nem lehet elvenni a futás jogát, amíg 
vissza nem tér felhasználó módba. A megszakítások azon- 
ban akkor is elvonhatják a processzor figyelmét, amikor ép- 
pen egy rendszermag módban futó folyamattal foglalkozik. 
Ezzel a megoldással növelni lehet a rendszer átviteli sebes- 
ségét. Amikor megszakítás érkezik, a processzor felfüggeszti 
az éppen futó folyamatot, majd a megszakítást okozó ese- 
mény jellegétől függően lefuttatja a megfelelő kódot. 
A számítógép minden eszköze rendelkezik egy eszközve- 
zérlővel, valamint egy olyan hardveres érintkezővel, ame- 
lyet akkor használ jelzésre, amikor szüksége van a pro- 
cesszor közreműködésére. Ez az érintkező a processzor 
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megfelelő megszakításlábához csatlakozik, ezen keresztül 
folyik az adatcsere. A processzor vezérlőhöz csatlakozó lá- 
bát megszakításkérési vonalnak nevezzük. Egy processzor 
több ilyen lábbal is rendelkezik, vagyis több eszközzel is ké- 
pes tartani a kapcsolatot. A korszerű operációs rendszerek- 
nél egy programozható megszakításvezérlő (programmable 
interrupt controller, PIC) kezeli a processzor és az eszköz- 
vezérlők közötti IRO-vonalakat. Az egyes rendszerekben 

a szabad IRO-k száma korlátozott, ám a Linux rendelkezik 
egy olyan megoldással, amelynek révén több eszköz is osz- 
tozhat ugyanazokon a megszakításokon. 

A megszakítások használata a programozók munkájához 
hasonlítható. A programozó megnyitja a postaládáját, majd 
nekikezd szokásos munkájának. Amikor új levele érkezik, 
akkor rövid hangjelzést hall, valamint a képernyő alján 
valamilyen egyéb jelzés is megjelenik. Azonnal elmenti 

a programot, amin éppen dolgozik, majd átvált a postalá- 
dára. Elolvassa a levelet, küld egy visszaigazolást, majd 
folytatja imént abbahagyott munkáját. Az általa végrehaj- 
tott lépések részletes listáját valamikor később küldi el. 
Hasonlóan, amikor egy processzor futtat egy folyamatot, az 
eszközök az egyes feladatokhoz kapcsolódóan megszakításo- 
kat küldhetnek neki, például jelezve, hogy valamilyen adat 
készen áll az átvitelre. Amikor befut egy megszakítás, a pro- 
cesszor azonnal elmenti a programszámláló aktuális értékét 
a rendszermag módú verembe, majd végrehajtja a megfelelő 
megszakításkiszolgáló eljárást (interrupt service routine, ISR). 
Az ISR egy függvény a rendszermagban, feladata a megsza- 
kítás jellegének meghatározása és a szükséges művelet vég- 
rehajtása, például egy adatblokk másolása a merevlemezről 
a központi memóriába. Az ISR lefuttatása után a processzor 
visszaállítja a korábbi folyamatot, és folytatja a futtatását. 

Az illesztőprogram egy a rendszermagba beépülő, az alkal- 
mazások kéréseit fogadó programmodul. Amikor egy alkal- 
mazás adatokat szeretne olvasni egy eszközről, akkor azon- 
nal meghívásra kerül a megfelelő illesztőprogram, majd 
megnyílik olvasásra a kívánt eszköz. Ha a rendszer sokat 
vár a lassú eszközökre, akkor nem tud a feladataival foglal- 
kozni. A rendszermag fejlesztőinek egyik fő célja az erőfor- 
rások minél jobb kihasználásának biztosítása. Mivel nem 
akar a hardvereszközök által szállított adatokra várakozni, 








a rendszermag kiadja a feladatot az eszközvezérlőnek, 
majd visszatér a felfüggesztett folyamathoz. Amikor az ol- 
vasás befejeződött, az eszköz egy megszakítás segítségével 
értesíti a processzort, amely végrehajtja a megfelelő ISR-t. 


A megszakítások osztályozása 

A megszakításokat két fő kategóriára osztjuk, szinkron és 
aszinkron megszakításokra. A szinkron megszakításokat 

a processzor vezérlőegysége hozza létre valamilyen utasítás 
végrehajtásakor. A vezérlőegység akkor adja ki a megszakí- 
tást, amikor végzett az utasítások végrehajtásával, innen 
származik a szinkron jelző. Az aszinkron megszakításokat 
a hardvereszközök hozzák létre, véletlenszerűen, bár a pro- 
cesszoróra állásához igazodva. Az Intel alapú gépeknél az 
első típust kivételnek, a másodikat pedig megszakításnak 
nevezzük. A megszakításokat egy előjel nélküli, egybájtos 
egész azonosítja, ezt vektornak nevezzük. A vektortarto- 
mány a 0 - 255. Az első 32 (0 - 31 sorszámú) vektor a kivéte- 
leket, más néven nem maszkolható megszakításokat azono- 
sítja, ezekről , Linuxos jelzések alkalmazásfejlesztői szem- 
szögből" (Linuxvilág, 2003. július) című cikkemben volt szó. 
A 32 - 47 tartomány a maszkolható megszakításoké, ezeket 
hozzák létre az IRO-k (a 0 - 15 számú IRO-vonalak). 

Az utolsó tartomány a 48 - 255, ebbe a szoftveres megsza- 
kítások tartoznak. Ilyen például a rendszerhívások megva- 
lósítására használt 128-as megszakítás (int 0X80 assembly 
utasítások). 


IRO-kiosztás 

A rendszer már használatban lévő megszakításairól 

a /proc könyvtárban találunk pillanatképet. A $cat 
/proc/interrupt parancs a megszakításokkal kapcsolatos 
adatokat jeleníti meg. A saját gépemen a következő volt 

a kimenete: 


CPUO 
0 82821789 XT-PIC timer 
1: 122 XT-PIC 18042 
Zs 0 XT-PIC cascade 
8: 1 XT-PIC rtc 
10: 154190 XT-PIC eth0 
T2: 100 XT-PIC 18042 
14: 21578 XT-PIC ide0 
15 18 XT-PIC idel 

NMI: 0 

ERR: 0 


Az első oszlopban az IRO-vonalak száma (32 - 47 vektortar- 
tomány) látható, a másodikban pedig az, hogy az egyes 
megszakítások a rendszer elindítása óta hányszor jutottak 
el a processzorhoz. A harmadik oszlop a PIC-kel kapcso- 
latos, az utolsó pedig azoknak az eszközöknek a nevét 
tartalmazza, amelyek kezelőt jegyeztek be az egyes meg- 
szakításokhoz. 

Ha egy illesztőprogramot dinamikusan akarunk betölteni, 
akkor először használaton kívüli IRO-vonalat kell találnunk 
a rendszerben. A reguest. irg függvény segítségével meg- 
határozott azonosítójú IRO-vonalat rendelhetünk az eszkö- 
zünkhöz. A reguest. ira szintaxisának meghatározása 

a linux/sched.h fájlban található: 
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int 
reguest irg (unsigned int irg, 
void (Ghandler) (Cint, void ", 
struct pt. regs "), 
unsigned long flags, 
const char "device, void "dev id); 


A függvény átadott értékeinek szerepe a következő: 

e  unsigned int ira: A rendszertől kért megszakítás száma. 

e void Ghandler) Cint, void 7, struct pt. regs 7"): 
Megszakítás kérésekor gondoskodnunk kell a kezelését 
végző ISR-ről, egyébként a processzor egyszerűen 
nyugtázza, majd nem történik semmi. Az átadott érték 
a kezelőfüggvényre mutat. A kezelőfüggvény szintaxisa 
a következő: 


void 
handler Cint irg, void "dev id, 
struct pt regs "regs); 


Az első átadott érték az IRO száma, erről a reguest, irg 
függvény kapcsán már volt szó. A második átadott érték 
egy fő- és egy alrészből álló eszközazonosító, ez adja 
meg az aktuális megszakítási esemény kezelését végző 
eszközt. A harmadik átadott értéket a folyamat környe- 
zetének a rendszermag verembe mentésére használjuk, 
mielőtt a processzor megkezdené a megszakításkezelő 
függvény futtatását. A korábbi folyamat visszaállításakor 
a rendszer ezt az adatszerkezetet használja fel. Normál 
esetben az illesztőprogramok íróinak ezzel az átadott 
értékkel nem kell foglalkozniuk. 

e  unsigned long flags: A flags változó a megszakításke- 
zelésben jut szerephez. Az SA INTERRUPT jelzőt gyors 
megszakításkezelőknél használjuk, ez minden 
maszkolható megszakítást letilt. AZ SA SHIRO-t akkor 
használjuk, ha az IRO-t egynél több eszköz közt akarjuk 
megosztani; az SA PROBE jelzőt akkor, ha az IRO-vonal 
segítségével le szeretnénk kérdezni egy hardvereszközt; 
az SA RANDOM jelző pedig a rendszermag véletlenszám- 
generátorának kezdeti értékadására használható. A jel- 
zőről további részleteket a /usr/src/linux/drivers/char/ 
random.c fájlban találni. 

e — constant char "device: Az IRO-t használó eszköz neve. 

e void "dev id: Az eszköz azonosítója, egy mutató az 
eszköz adatszerkezetére. Ha a megszakítás meg van 
osztva, akkor ez a mező meghatározott eszközre mutat. 


A reguest. irg függvény siker esetén nullával, a foglalás si- 
kertelenségekor pedig -EBUSY értékkel tér vissza. Az EBUSY 
a 16-os számú hiba, leírása a /usr/src/linux/include/asm/ 
errno.h fájlban található. A free ira függvény elengedi az 
adott eszköz IRO-ját. Szintaxisa a következő: 


free irg (unsigned int irg, void "dev id); 


Az argumentumok jelentése a fentiekkel egyezik meg. 

ISR meghívására megszakítás fellépésekor kerül sor. A meg- 
szakítás hatására végrehajtandó műveletek leírása az ISR- 
ben szerepel. A rendszermag fenntart a memóriában egy 

a megszakítási eljárások címeit (megszakításvektorokat) 
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1. kódrészlet my module.c 


finclude clinux/init.hz 
finclude clinux/zfs.hz 
finclude clinux/module.h: 
finclude clinux/sched.h: 
finclude clinux/interrupt.h: 
static struct file operations fops; 
Staticsíntámanos eng sesző 
static void OUrISR (int irg, void "device, 
struct pt. regs "regs) 
jú 
/" fontos és azonnali, időkritikus 
5 feladatok "/ 
s 
static int . init my init module(void) 
ü 
int status; 
Major - register chrdev(0, "ourDevice", 
5 €fops); 
if (Major -— -1) ( 
printk (" A dinamikus főazonosító 
"foglalása sikertelen.Mm"); 
return Major; 


3 
status — reguest irg(Cirag, 
(void ")OuUrISR, 
SA INTERRUPT, 
"ourDevice", €fops); 
MH NCStatus sss EBÜSYJET 
printk ("Az IRO-azonosító foglalása 
s sikertelen.m"); 
unregister chrdev(Major, "ourDevice"); 
return status; 


printk ("A modul sikeresen betöltve.n"); 

printk ("Az eszköz főazonosítója: d", 
Major); 

printk ("Az eszköz IRO-ja: 
ügye 

return 0; 


dm" , 


3 
static void . exit my cleanup module (void) 
jú 
printk("A(z) Xd főazonosító és a(z) d 
5 IRO-azonosító " 
"elengedése megtörtént.Xn", Major, 
dna 
free irgCirg, €gfops); 
unregister chrdev(Major, "ourDevice"); 


printk("A modul sikeresen eltávolítva.Mn") ; 


3 

module init (my init module); 
module exit (my cleanup module); 
MODULE. LICENSE ("GPL") ; 
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tartalmazó táblázatot. Amikor egy megszakítás érkezik, 

a processzor lekérdezi az ISR címét a megszakításvektorok 
táblázatából, majd lefuttatja. Az ISR feladata, hogy a meg- 
szakítás jellegétől — mint például írás vagy olvasás — függő- 
en válaszoljon az eszköznek. Általában az ISR alvó folya- 
matokat ébreszt fel az eszközön, ha a megszakítás olyan 
eseményt jelez, amire éppen várnak. 

Azt az időt, amit a processzor egy-egy megszakítás kezelé- 
séhez igényel, megszakítási lappangási időnek nevezzük. 

A megszakítási lappangási idő része a hardveres jelterjedési 
idő, a regiszterek elmentésének ideje és a szoftveres terje- 
dési idő. A rendszer teljesítményének javításához a megsza- 
kítási lappangási időt a lehető legkisebbre kell csökkenteni, 
ezért az ISR-nek rövidnek kell lennie, és a megszakításokat 
csak rövid időre tilthatja le. A megszakítások letiltása alatt is 
jelentkezhetnek további megszakítások, ám a processzor fi- 
gyelmen kívül hagyja őket, amíg a megszakítások újraenge- 
délyezése meg nem történik. Ha egynél több megszakítás 
van blokkolva, a processzor fontossági sorrendben engedé- 
lyezi őket, amikor késszé válik a kezelésükre. 

Az illesztőprogramok készítőinek az illesztőprogramok 
kódjában csak akkor szabad letiltaniuk a megszakításokat, 
ha valóban szükséges, mert ilyenkor a rendszer nem frissíti 
az időzítőket, nem továbbítja a hálózati csomagokat a puffe- 
rek felé és felől, és így tovább. Az ISR-eket úgy kell megírni, 
hogy más folyamatok számára is biztosítsák a processzor el- 
érhetőségét. A való világban viszont az ISR-ek hosszas fel- 
adatokat kezelnek. Ilyenkor az ISR csak az időkritikus adat- 
cseréket végezheti el a hardverrel, és a taskletet kell hasz- 
nálnia a tényleges adatátvitel lebonyolítására. A tasklet 

a legújabb Linux rendszermag egy különleges szolgáltatása, 
amely a megszakításokkal kapcsolatos műveletek egy részé- 
nek megfelelő időben való elvégzésére alkalmas. A tasklet 

a szoftveres megszakítás, és más megszakítások által meg- 
szakítható. A megszakítások belső világáról Bovet és Cesati 
írásából (lásd az internetes forrásokat) lehet tájékozódni, 

a megszakítások megvalósítását — az illesztőprogramok né- 
zőpontjából szemlélve — pedig Rubini és Corbet tárgyalja. 


Egy egyszerű megvalósítás 

A rendszermagmodulok illesztőprogramokat tartalmaznak, 
ezeket a meglévő rendszermaghoz, akár a rendszer működé- 
se közben lehet betölteni. A dinamikus IRO-kiosztást az 

1. kódrészletben szereplő egyszerű modullal szeretném szem- 
léltetni. Egy egyszerű karakteres eszközhöz készült illesztő- 
programról van szó, az eszközt nevezzük OurDevice-nak 
(SajátEszköz), ehhez foglalunk dinamikusan IRO-vonalat. 

A modul beillesztésekor az init module függvény fut le. 

Ha a foglalás sikeres, akkor kiírjuk az eszköz főazonosítóját 
és a kapott IRO számát. Ettől a pillanattól az IRO kiosztását 
a /proc könyvtárban is ellenőrizhetjük. A kapott IRO-t a mo- 
dul eltávolításakor elengedjük. IRO-azonosítót a kódon belül 
legjobban egy nyílt belépési ponton lehet bejegyezni, amely 
a megfelelő pillanatban az elengedésről is gondoskodik. 

A my module.c fájlt a 2.6.0-0.test2.1.29 rendszermag alatt 
fordítottam le. A kernel-2.6.0-0.test2.1.30.i586.rpm fájlt az 
összes szükséges RPM-el együtt kell letölteni és telepíteni. 
Az RPM-et a people.redhat.com/arjanv/2.5/RPMS.kernel 
címen érhetjük el, az illesztőprogram fordítását pedig 

a következőképpen kell elvégeznünk: 








gcc -wall -03 -finline-functions N 
-Wstrict-prototypes -falign-functions-4á N 
-I/Tib/modules/2.6.0-O.test2.1.29/build/include N 
-I/1Tib/modules/2.6.0-O.test2.1.29/build/include/ 
?asm/mach-default 

-I./include -D KERNEL ". -DMODULE -DEXPORT SYMTABN 
-DKBUILD. MODNAME-my module -c my module.c -oN 

my module.o 


A my module.o betöltése után — ha a főazonosító és az IRO 
foglalása sikeres — a megfelelő üzenetek jelennek meg. Ha 
az IRO-azonosítót egy másik eszköz már használta, akkor 
a rendszermag törli az eszköz bejegyzését, és felszabadítja 
a főazonosítót. A $cat /proc/interrupt parancs a követ- 
kező kimenetet jeleníti meg: 


CPUO 
0 82887219 XT-PIC timer 
1: 122 XT-PIC 18042 
Za 0 XT-PIC cascade 
7 0 XT-PIC OurDevice 
8: 1 XT-PIC rtc 
TO 154769 XT-PIC eth0 
12: 100 XT-PIC 18042 
14: 21636 XT-PIC ide0 
15: 18 XT-PIC idel 
NMI: 0 
ERR: 0 












A kimenetben látható az ourDevice-hoz tartozó bejegyzés, 
illetve az eszköz IRO-ja. Amikor a modult eltávolítjuk, 

a rendszermag felszabadítja az IRO-azonosítót és a főazo- 
nosítót, valamint törli a készülék bejegyzését. 


Osszefoglalás 

Remélem, hogy sikerült tisztáznom a megszakításokkal és 
a kezelésükkel kapcsolatos alapokat. A reguest. irg és 

a free irg függvényt elsősorban illesztőprogramok készí- 
tésekor érdemes ismerni, a dinamikus IRO-foglalási eljárást 
pedig egy egyszerű karakteres eszköz illesztőprogramjával 
szemléltettük. 
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Niért és hogyan használjunk 


Netlink Socket-eket 


Használjuk kétirányú, alakítható módszert a rendszermag és a felhasználói 


tér közötti adatátadásra. 


rendszermag fejlesztése és karbantartása elég ko- 
A moly feladat, ezért csak a legszükségesebb és telje- 
sítmény szempontból legfontosabb kódok kerül- 
nek a magba. Más részek, mint a GUI, kezelési és vezérlő 
kód, általában felhasználói térben futó programként készül- 
nek. Elég általános gyakorlat Linux alatt, hogy egy bizonyos 
képességet megvalósításkor felosztanak a rendszermag és 
a felhasználói tér között. Most már csak az a kérdés, hogy 
a rendszermag kód és a felhasználói tér hogyan kommuni- 
kálnak egymás között? 
A válasz a rendszermag és a felhasználói tér közötti külön- 
féle IPC módszerekben rejlik. Ilyen a rendszerhívás, az 
ioctl, a proc fájlrendszer vagy a netlink socket. Ez a cikk 
a netlink sockettel foglalkozik és megpróbál rávilágítani en- 
nek a hálózatbarát IPC-nek az előnyeire. 


Bevezetés 

A netlink socket egy különleges IPC, melyet a rendszermag 

és a felhasználói térbeli folyamatok közötti információcseré- 

re használunk. Teljes kétirányú kommunikációs csatornát 
létesít a két rész között ahol a felhasználói folyamatok szab- 
ványos socket API-t a rendszermag modulok pedig egy kü- 
lönleges API-t használnak. A netlink socket az AF NETLINK 
címcsaládot használja szemben a TCP/IP socketek által 
használt AF. INET címekkel. Minden netlink socket képesség 

a include/linux/netlink.h rendszermag fejléc fájlban definiál- 

ja saját protokolltípusát. 

Az alábbiakban bemutatunk a netlink socket által támoga- 

tott néhány képességet és protokolltípust: 

e  NETLINK ROUTE: a felhasználói tér útvonalválasztó 
démonai között használt kommunikációs csatorna. 
Ilyen például a BGP, OSPE, RIP és a rendszermag 
csomagtovábbító modul. A felhasználói tér útvonalvá- 
lasztó démonai a rendszermag útvonalválasztó tábláját 
frissítik ezzel a netlink protokolltípussal. 

0  NETLINK FIREWALL: Az IPv4 tűzfal kód által küldött 
csomagokat fogadja. 

e  NETLINK NFLOG: a felhasználói tér iptable kezelő 
eszközei és rendszermag tér Netfilter modulja közötti 
kommunikációs csatorna. 

e — NETLINK ARPD: az arp tábla kezelése felhasználói térből. 
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De miért használnak a fentiek netlink kapcsolatot rendszer- 
hívás, ioctl vagy proc fájlrendszer helyett a felhasználói és 
a rendszermag világ közötti kommunikációhoz? Az új ké- 
pességekhez tartozó rendszerhívások, ioctl-ek vagy proc 
fájlok elkészítése egyáltalán nem egyszerű; sőt azt kockáz- 
tatjuk, hogy belerondítunk a rendszermagba és ezzel az 
egész rendszer stabilitását veszélyeztetjük. A netlink socket 
viszont egyszerű: egyetlen konstanst, a protokoll típust kell 
a netlink.h-hoz fűznünk. Ezáltal a rendszermag modul és 
az alkalmazás egy socket-szerű API-n keresztül máris képes 
a kapcsolattartásra. 

A netlink aszinkron jellegű, ugyanis, akárcsak a a többi 
socket API, egy socket sort használ az üzenet rohamok csil- 
lapítására. A netlink üzenetet küldő rendszerhívás az üzen- 
tet a fogadó üzenetsorába helyezi, majd meghívja a fogadó 
átvétel kezelőjét. A fogadó az átvételkezelő környezetben 
(context)futva eldöntheti, hogy azonnal feldolgozza-e az 
üzenetet, vagy a sorban hagyva inkább később, más kör- 
nyezetben dolgozza azt fel. A netlink-el ellentétben, a rend- 
szerhívások szinkron feldolgozást igényelnek. Következés- 
képpen, ha a felhasználói térből rendszerhívással adunk át 
egy üzenetet a rendszermagnak, a rendszermag ütemezési 
felbontására is hatással lehetünk amennyiben az üzenet 
feldolgozása kellően hosszú ideig tart. 

A rendszermagban a rendszerhívásokat megvalósító kód 
fordítási időben kerül a magba; ezért rendszerhívás kódot 
nem tehetünk betölthető modulba, pedig a legtöbb eszköz- 
vezérlő ezen az elven alapszik. A netlink socket esetében 
nincs fordítási idejű függőség a Linux netlink magja és a be- 
tölthető modulokban található netlink alkalmazások között. 
A netlink socket támogatja a multicasot, ez újabb előnyt jelent 
a rendszerhívásokkal, ioctl és proc megoldásokkal szemben. 
A folyamat multicast üzenetet küldhet egy netlink csoport- 
címre, melyre tetszőleges számú más folyamat hallgathat. 

Ez a rendszermagból a felhasználói térbe irányuló majdnem 
tökéletes eseményelosztási lehetőséget biztosít számunkra. 

A rendszerhívások és az ioctl IPC-k egyirányúak abban az ér- 
telemben, hogy ilyen IPC-t csak felhasználói térben futó alkal- 
mazások kezdeményezhetnek. De mit tegyünk ha egy rend- 
szermag modul szeretne sürgős üzenetet küldeni a felhaszná- 
lói tér alkalmazásainak? Ezekkel az IPC-kel ezt nem tudjuk 








közvetlenül megvalósítani. Az alkalmazásnak általában adott 
időnként le kell kérdeznie a rendszermagot, hogy tudomást 
szerezzen az állapotváltozásokról, azonban az intenzív lekér- 
dezés erőforrásigényes. A netlink viszont ügyesen megoldja 
ezt a problémát, hiszen lehetővé teszi, hogy a rendszermag is 
küldhessen üzeneteket. Ezért mondjuk, hogy a netlink socket 
kétirányú (duplex) képességekkel rendelkezik. 

Végül a netlin socket BSD socket jellegű API-t nyújt amit 

a programfejlesztő közösség kiválóan ismer. Következéskép- 
pen a képzési költség jóval alacsonyabb mint egy meglehető- 
sen titokzatos rendszerhívás API-t vagy ioctlt használnánk. 


Osszehasonlítás a BSD útvonalválasztó sockettel 

A BSD TCP/IP verem megvalósításban van egy különleges 
socket, amelyet routing socketnek neveznek. Ennek címcsa- 
ládja az AF. ROUTE, protokollcsaládja a PF. ROUTE socket típu- 
sa pedig a SOCK RAWw. BSD alatt a folyamatok arra használják 
az útvonalválasztó socketet, hogy a rendszermag útvonalvá- 
lasztó táblájához útvonalakat fűzzenek vagy távolítsanak el. 
Linux alatt, az útvonalválasztó socketnek a netlink socket 
NETLINK ROUTE protokolltípusa felel meg. A netlink socket 
képességkészlete tehát a BSD útvonalválasztó socket képes- 
ségeinek bővített halmaza. 


Netlink Socket API 

A felhasználó alkalmazások a szabványos socket API 
(socket) , sendmsgO, recvmsg0) és close) segítségével 
érhetik el a netlink socketet. Az API részletes meghatározá- 
sait a kézikönyvoldalakon találjuk. Itt most csak azzal fog- 
lalkozunk, hogyan válasszunk paramétereket az API-hoz 

a netlink socket használata során. Az API ismerős kell le- 
gyen mindenkinek, aki már készített hagyományos TCP/IP 
socketet használó hálózati alkalmazást. A socketO segítsé- 
gével a következőképpen készíthetünk új socketet: 

int socket(Cint domain, int type, int protocol) 


A socket tartomány (címcsalád) jelen esetben az AF NETLINK, 
a socket típus pedig vagy SOCK RAW vagy SOCK DGRAM lesz, 
ugyanis a netlink datagram-jellegű szolgáltatás. 

A protocol (protokolltípus) határozza meg, hogy melyik 
netlink képességhez használjuk a socketet. Az előre definiált 
netlink protokolltípusok közül néhány: NETLINK ROUTE, 
NETLINK FIREWALL, NETLINK ARPD, NETLINK ROUTEG és 

a NETLINK IP6. Fw. Saját magunk is könnyen felvehetünk 
új protokolltípusokat. 

Minden netlink protokolltípushoz maximum 32 multicast 
csoportot adhatunk meg. Minden multicast csoportot az 
1cci bitmaszk képviseli, ahol 0c-i c—31. Ez rendkívül hasz- 
nos lehet ha azonos képességen dolgozó folyamatcsoport és 
a rendszermag koordinálását kell megoldanunk. A multicast 
netlink üzenetek küldésével csökkenthetjük a szükséges 
rendszerhívások számát és megkímélhetjük az alkalmazáso- 
kat, hogy a multicast csoporttagságukkal bajlódjanak. 


bind() 

Akárcsak a TCP/IP socket, a netlink bindO API is helyi 
(forrás) socket címeket rendel a megnyitott socketekhez. 
A netlink címszerkezete a következő alakú: 

struct sockaddr n! 


í 
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sa family t n1] family; /" AF NETLINK — "/ 
unsigned short ni pad; /" zero 4/ 
saÚ32 n] pid; /" folyamat pid "/ 

— u32 n] groups; /" mcast csoportmaszk "/ 
) nladdr; 


A bindO használata során a sockaddr. n] n1] pid mezőjé- 
ben elhelyezhetjük a hívó folyamat saját azonosítóját. 
Ígyittaz ni]. pid szolgál a netlink socket helyi címeként. 
Az alkalmazás felelőssége, hogy az n1. pid-et egyedi 
32-bites egész számmal töltse fel: 

NL PID Formula 1: ni] pid — getpidO; 


Az 1. formula az alkalmazás folyamat azonosítóját használja 
n1. pid értéknek, amely teljesen természetes választás, felté- 
ve, hogy az adott netlink protokolltípus esetében a folya- 
matnak csak egyetlen netlink socketre van szüksége. 
Azokban az esetekben, amikor ugyanazon folyamat külön- 
féle szálai azonos netlink protokollba tartozó, de egyedi 
netlink socketeket nyitnak meg, a 2. formulát használhatjuk 
az ni] pid létrehozására: 

NL PID Formula 2: pthread selfO cc 16 ] getpidO; 


Ezzel a módszerrel, egyazon folyamat különféle pthreads 
szálai azonos netlink protokoll típushoz tartozó de egyedi 
netlink socketet hozhatnak létre. Tulajdonképpen akár 
egyetlen pthread is nyithat több azonos protokollba tarto- 
zó netlink socketet. A fejlesztőknek persze kicsit kreatí- 
vabbnak kell lenniük az n1. pid értékek készítésekor, 

de úgy gondolom ezt nem igazán tekinthetjük szokásos 
felhasználásnak. 

Ha az alkalmazás fogadni szeretné az adott multicast cso- 
portnak küldött netlink üzeneteket egy adott protokolltípus 
esetén, az összes vonatkozó mulicast csoport azonosítóját 
össze-OR-olva készítheti el az sockaddr. n1] n1]. groups 
mezőjét. Egyébként az n1. groups értéke nulla, így az alkal- 
mazás kizárólag a neki szánt és a protokolltípushoz tartozó 
ünicast" üzeneteket kapja meg. Az nladdr kitöltése után 

a következő formában bind-elünk: 

bind(fd, (Struct sockaddr")enladdr , 
sizeof(nladdr)); 


Netlink üzenet küldése 

Amikor a rendszermagnak vagy egy más felhasználói folya- 
matoknak netlink üzenet küldünk, cél címként egy másik 
struct sockaddr. n] nladdr értéket kell megadnunk, ép- 
pen úgy ahogyan UDP csomagot küldenénk a sendmsgO- 
el. Ha az üzenetet a rendszermagnak szánjuk, az n] pid és 
az n1. groups értéke 0. 

Ha az üzenet egy másik folyamatnak szánt unicast üzenet, 
az n1. pid a folyamat pid azonosítója az n] groups pedig 0, 
feltételezve, hogy rendszerünkben az 1. formulát használjuk. 
Amennyiben az üzenet egy vagy több multicast csoportnak 
szánt multicast üzenet, valamennyi multicast csoportot 
össze-OR-olva képezzük az n1. groups mezőbe írandó masz- 
kot. Ezek után a netlink címet beírhatjuk a sendmsgO API- 
hoz tartozó struct msghdr msg szerkezetbe: 

struct msghdr msg; 

msg.msg. name - (void ")8á(nladdr); 

msg.msg. namelen - sizeof(nladdr); 
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A netlink socketnek saját üzenetfejlécre is szüksége van. 
Ezzel biztosítjuk a közös alapot valamennyi protokolltípus 
netlink üzenetei számára. 

Minthogy a Linux rendszermag netlink magja a követke- 
ző fejlécet keresi minden netlink üzenetben, az alkalma- 
zásnak ezt a fejlécet minden elküldött setlink üzenetben 
át kell adnia: 


struct nilmsghdr 


t 
— u32 ni]msg len; /" Üzenet hossza "/ 
- ul6 nilmsg type; /" Üzenettípus "/ 
- u16 nimsg flags; /" Kiegészítő jelek "/ 
— U32 nilmsg seg; /: Sorszám "/ 
— u32 ni]msg pid; /: Küldő folyamat PID "/ 
b; 


Az nimsg len elemet a netlink üzenet teljes hosszával 
kell feltölteni, beleértve a fejlécet is, és kötelezően 

meg kell adni a netlink magnak. Az n1msg. type értéket 
az alkalmazások használhatják és a netlink mag számár 
nem bír jelentőséggel. Az nimsg. flags segítségével 
további üzenetvezérlést hajthatunk végre; ezt a netlink 
mag beolvassa és frissíti. Az nimsg seg és nimsg pid 
értékeket az alkalmazások használják az üzenetek 
nyomon követésére, és a netlink mag számára szintén 
lényegtelenek. 

A netlink üzenet tehát a nImsghdr fejlécből és az üzenet 
adataiból áll. Miután bevittük az üzenetet, az n]h mutató 
által megadott pufferbe kerül. Az üzenetet a struct msghdr 
msg szerkezetnek is elküldhetjük: 


struct iovec iov; 

iov.iov base -— (void ?)nih; 
jiov.iov len - n1h-:nimsg len; 
msg.msg.iov — giov; 
msg.msg.iovlen — 1; 


A fenti lépéseket követően, a sendmsgO meghívásával kilő- 
hetjük a netlink üzenetet: 
sendmsg(fd, €msg, 0); 


Netlink üzenetek fogadása 

A fogadó alkalmazásnak fenn kell tartania egy kellően nagy 
puffert amelyben az üzenet fejléce és az üzenet tartalma 
elfér. Ezek után az alább látható módon feltölti a struct 
msghdr msg szerkezetet majd a szabványos recvmsgO hí- 
vással fogadja a netlink üzenetet, feltételezve, hogy az n1h 
a bufferünkre mutat: 


struct sockaddr ni] nladdr; 
struct msghdr msg; 
struct iovec iov; 

(void ")nih; 
MAX NL MSG LEN; 
msg. name -— (void ")é(nladdr); 
msg. namelen — sizeof(nladdr); 
msg.msg.iov — giov; 
msg.msg.iovlen — 1; 

recvmsg(fd, 8msg, 0); 


iov.iov base — 
iov.iov len — 

msg. 
msg. 
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Miután az üzenet helyesen megérkezett, az n1h az éppen 
megérkezett netlink üzenet fejlécére kell mutasson. A foga- 
dott üzenet célcímét az nladdr tartalmazza, amely a pid-ből 
és az üzenet címzettjeként megadott multicast csoportból 
áll. A netlink.h-ban definiált NLMSG DATA(n1h), a netlink 
üzenet tartalmára mutat. A close(fd) hívás lezárja az fd 
leíró által megadott setlink socketet. 


Netlink API a rendszermag térben 

A rendszermag térben futó netlink API-t a rendszermag 
net/core/af netlink.c netlink magja kezeli. A rendszermag 
oldaláról nézve, az API eltérő a felhasználó térbeli API-tól. 
Az API-t a rendszermag modulok használhatják a netlink 
socketek elérésre és a felhasználói alkalmazásokkal való pár- 
beszédhez. Amennyiben nem a már meglévő netlink socket 
protokoll típusokkal dolgozunk, saját protokolltípusunkat 
állandóként fel kell vennünk a netlink.h állományba. 
Például, a tesztelési céllal készülő protokollunk felvételéhez 
a következő sort kell a netlink.h-ba illesztenünk: 

fdefine NETLINK TEST 17 


Ezt követően a felvett protokolltípusra a Linux rendszer- 
magban bárhol hivatkozhatunk. 

A felhasználói térben a socket függvényt hívtuk 

a netlink socket készítésekor, kerneltérben azonban, 

a következő API-t indítjuk: 


struct sock " 

netlink kernel createCint unit, 
void ("input)(struct sock "sk, int 
5 1en)); 


A unit paraméter nem más mint a netlink protokolltípus, 
azaz például a NETLINK TEST. Az input függvénymutató 
lesz az a visszahívott függvény, amelyre az üzenetek érkez- 
nek a netlink socketünkben. 

Miután a rendszermag létrehozta a NETLINK TEST proto- 
kollhoz tartozó netlink socketet, valahányszor a felhasználói 
térből egy NETLINK TEST protokoll típusú üzenet érkezik 

a rendszermaghoz, a netlink kernel createO-el regiszt- 
rált az inputO visszahívott függvény indul el. Nézzünk 
egy példát a visszahívott függvény megvalósítására: 


void input (struct sock "sk, int len) 
í 
struct sk buff "skb; 
struct nimsghdr "nlh -— NULL; 
u8 "payload - NULL; 
while ((skb - skb degueue(gsk-sreceive gueue)) 
1- NULL) ( 
/" feldolgozzuk a skb-sdata által megadott netlink 
5 üzenetet"/ 
nih - (struct n]imsghdr ")skb-sdata; 
payload -— NLMSG DATA(n1h) ; 
/:" Feldolgozzuk az üzenetet n1lh-val jelölt 
5 fejlécét 
s: és a payload által jelölt tartalmát 
7 
3 
3 








Ez az inputO függvény indul majd el a küldő folya- 

mat által elindított sendmsg) rendszerhívás környeze- 
tében. A netlink üzenetet az input() függvényben is 

fel lehet dolgozni, feltéve, hogy elég gyors. Amikor 

a netlink üzenet feldolgozása hosszú időt venne igény- 
be, jobb ha az input() függvényen kívül helyezzük el, 
hogy ne blokkoljuk a többi rendszerhívás belépést 

a rendszermagba. Egy külön erre a célra fenntartott 
rendszermag szálat használunk a következő lépések 
végrehajtására. Végrehajtjuk az skb - 

skb. recv datagram(n1. sk) kifejezést, ahol az n1. sk 
netlink kernel createO-tól visszakapott nzetlink socket. 
Aztán feldolgozzuk az skb-:data által mutatott netlink 
üzenetet. 

Ez a rendszermag szál mindaddig alszik, amíg nincs netlink 
üzenet az n1. sk szerkezetben. Így aztán az input() visszahí- 
vott függvényünkben csak fel kell ébresztenünk az alvó 
rendszermag szálat, valahogy így: 


void input (struct sock "sk, int len) 
1 
wake up. interruptible(sk-ssleep) ; 


: 


Ez egy méretezhetőbb megoldás a felhasználói tér és 
a rendszermag között. Emellett a környezetváltások 
felbontását is javítja. 


Netlink üzenetek küldése a rendszermagból 

Akárcsak a felhasználói térben, a netlink üzenet kiküldé- 
sekor be kell állítanunk a forrás és a cél netlink címét. 
Feltételezve, hogy az elküldendő üzenetet tartalmazó socket 
buffer neve sk buff "skb, a helyi címet a következőképpen 
állíthatjuk be: 

NETLINK. CB(skb) .groups - 
NETLINK. CB(skb).pid — 0; 


local. groups; 
/" a rendszermagból"/ 


A cél címét pedig így adjuk meg: 
NETLINK CB(skb).dst groups - dst groups; 
NETLINK. CB(skb).dst pid — dst pid; 


Az ilyen információt nem tároljuk az skb-:data elem- 
ben. Ehelyett az skb socket buffer netlink vezérlő- 
blokkjába kerül. 

Az unicast üzenet elküldéséhez a következőket 
használjuk: 


int 
netlink unicast(struct sock "ssk, struct sk buff 
:"skb, u32 pid, int nonblock); 


Ittaz ssk a netlink kernel create(), által visszaadott 
netlink socket az skb-:data az elküldendő netlink üzenetre 
mutat a pid a fogadó alkalmazás pid-je, feltételezve, hogy 
az 1. NLPID formulát alkalmaztuk. A nonblock jelzi, hogy 
ha a fogadó puffer nem érhető el az API blokkoljon-e vagy 
azonnal térjen vissza hibával. 

Multicast üzeneteket is küldhetünk. A következő API 

a netlink üzenetet kézbesít a pid által meghatározott folya- 
matnak és a group (csoport) által megadott csoportoknak: 
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void 
netlink broadcast(struct sock "ssk, struct sk buff 
"skb, u32 pid, u32 group, int allocation); 


A group a fogadó csoportok OR művelettel egyesített 
bitmaszkja. Az allocation a rendszermag memória fog- 
lalási típusa. Általában GFP. ATOMIC típust adunk meg 

ha megszakítás környezetről van szó, egyébként pedig 
GFP. KERNEL-t. Ez azért lényeges, mert az API egy vagy 
több puffert is kénytelen lehet lefoglalni amikor lemásolja 
a multicast üzenetet. 


Netlink Socket lezárása a rendszermagból 

A netlink kernel. create() által visszaadott struct sock 
"n1. sk segítségével meghívhatjuk a következő rendszer- 
mag API-t, amely a rendszermagban lezárja a netlink 
socketet: 

sock release(nl] sk-ssocket); 


Eddig csak a legminimálisabb keretrendszer kódot 
mutattuk be a netlink programozás demonstrálására. 
Most használjuk a NETLINK. TEST netlink protokoll tí- 
pust és tételezzük fel, hogy már hozzá van adva 

a rendszermag fejléchez. Az itt bemutatott rendszermag 
modul kód csak a netlink vonatkozású részekkel foglal- 
kozik, tehát mindezt még be kellene illeszteni egy rend- 
szermag modul vázba, amit rengeteg egyéb ismertetőben 
megtalálunk. 


A rendszermag és az alkalmazás közötti Unicast 
kommunikáció 

Példánkban, a felhasználói tér folyamatai küldenek üze- 
neteket a rendszermagnak, a rendszermag modul pedig 
visszajuttatja az üzenetet a küldő folyamatnak. Íme a fel- 
használói tér kódja: 


finclude csys/socket.h: 
$finclude clinux/netlink.hz:z 
ftdefine MAX PAYLOAD 1024 4/" maximális tartalom 
s mérete"/ 
struct sockaddr n] src addr, dest addr; 
struct nimsghdr "nlh - NULL; 
struct iovec iov; 
int sock fd; 
void mainŐ ( 
sock fd - socket(PF NETLINK, 
SOCK. RAW, NETLINK. TEST) ; 
memset(€src addr, 0, sizeof(src addr)); 
src  addr.nl] family - AF NETLINK; 
src addr.nl] pid - getpidO; /" saját pid "/ 
src addr.nl groups — 0; /7" nincs mcast csoportban 
8 / 
bind(sock fd, (struct sockaddr")f€src addr, 
sizeof(src addr)); 
memset(gdest addr, 0, sizeof(dest addr)); 
dest addr.nl] family - AF NETLINK; 
dest addr.nl pid — 0; /" A Linux rendszermagnak 
93 / 
dest addr.nl] groups — 0; /" unicast "/ 
n1h-(struct n]lmsghdr ")Jmalloc( 
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NLMSG. SPACE (MAX. PAYLOAD) ) ; 
netlink üzenetfejlécet "/ 
n1h-:nimsg. len NLMSG. SPACE(MAX PAYLOAD) ; 
n1h-:nimsg pid - getpidO; /" self pid 7/ 
n1h-:nimsg flags - 0; 

/" Feltöltjük a netlink üzenetet tartalommal "/ 
strcpy(NLMSG DATA(n1h), "Hello you!"); 

1ov.iov base -— (void ")nlh; 

i1ov.iov. len - n1h-:nimsg len; 

msg.msg name -— (void ")Jédest addr; 

msg.msg. namelen -— sizeof(dest. addr); 
msg.msg.iov - giov; 


/: kitöltjük a 


msg.msg.iovlen — 1; 

sendmsg(fd, 8msg, 0); 

/" Üzenet olvasása a rendszermagtól "/ 

memset(nlh, 0, NLMSG SPACE(MAX PAYLOAD),); 

recvmsg(fd, 8msg, 0); 

printf(" Received message payload: 95" , 
NLMSG. DATA (n1h)) ; 


/" Lezárjuk a netlink socketet "/ 
close(sock fd); 
3 


Most nézzük a rendszermag kódot: 


struct sock "nil sk — NULL; 
void nil data ready (struct sock "sk, int len) 
í 
wake up. interruptible(sk-ssleep) ; 
3 
void netlink test0 ( 
struct sk buff "skb -— NULL; 
struct nimsghdr "nlh - NULL; 
int err; 
u32 pid; 
n1] sk - netlink kernel create(NETLINK TEST, 
n1 data ready); 
/" várunk amig üzenet érkezik a felhasználói 
s térből "/ 
skb - skb recv datagram(nl sk, 0, 0, gerr); 
nih - (struct nimsghdr ")skb-:sdata; 
printkC"9s: received netlink message 
payload:9s5W" , 
— FUNCTION  , NLMSG DATA(n1h)); 
pid - n1h-snimsg pid; /" küldő folyamat pid-je "/ 
NETLINK. CB(skb) .groups - 0; /" nincs mcast 
5 csoportban 7"/ 
NETLINK. CB(skb).pid — 0; 
NETLINK CB(skb).dst pid -— pid; 
NETLINK CB(skb).dst groups —- 0; /" unicast "/ 
netlink unicast(nl sk, skb, pid, MSG DONTWAIT) ; 
sock release(nl sk-ssocket); 


/" a kernelből "/ 


Miután betöltöttük a fenti rendszermag kódot tartalmazó 
modult és lefuttatjuk az végrehajtható állományt, a fel- 
használói térben futó programunk következő üzenetet 
fogja kiírni: 

Received message payload: Hello you! 
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A dmesg kimenetében pedig a következőknek kell meg- 
jelennie: 

netlink test: received netlink message payload: 
Hello you! 


A rendszermag és az alkalmazás közötti multicast 
kommunikáció 

Ebben a példában két felhasználói térben futó alkalma- 
zás hallgat ugyanarra a netlink multicast csoportra. 

A rendszermag modul a netlink socketen keresztül 

egy üzenetet dob a multicast csoportnak, amelyet 
valamennyi alkalmazás megkap. Nézzük a felhasználói 
tér kódját: 


finclude csys/socket.h: 
finclude clinux/netlink.hsz 
fdefine MAX PAYLOAD 1024 /" maximális tartalom 
s mérete"/ 
struct sockaddr ni] src addr, dest addr; 
struct nimsghdr "nlh — NULL; 
struct iovec iov; 
int sock fd; 
void mainO ( 
sock fd-socket(PF NETLINK, SOCK RAW, 
NETLINK TEST); 
memset(€src addr, 0, sizeof(Ilocal addr)); 
src addr.nl family -— AF NETLINK; 
src addr.nl] pid - getpidO; /" saját pid "/ 
/" interested in group 1cc0 7/ 
src addr.nl groups — 1; 
bind(sock fd, (struct sockaddr")gsrc addr, 
sizeof(src addr)); 
memset(€dest addr, 0, sizeof(dest addr)); 
nih - (struct nimsghdr ")Jmalloc( 


NLMSG SPACE(MAX PAYLOAD)); 

memset(n1h, 0, NLMSG SPACE(MAX PAYLOAD)); 
iov.iov base -— (void ?)nlh; 
NLMSG SPACE(MAX PAYLOAD); 
msg.msg. name - (void ")édest addr; 
msg.msg. namelen - sizeof(dest addr); 
msg.msg.iov — giov; 
msg.msg.iovlen — 1; 

printf("waiting for message from kernelm"); 
/" üzenet beolvasása a rendszermagból "/ 
recvmsg(fd, 8msg, 0); 

printf(" Received message payload: 95" , 

NLMSG. DATA (n1h)); 
close(sock fd); 


iov.iov len — 


A rendszermag kód a következőképpen néz ki: 


fdefine MAX PAYLOAD 1024 
struct sock "nil sk — NULL; 
void netlink test0 ( 
sturct sk buff "skb -— NULL; 
struct nimsghdr "nlh; 

int err; 








n] sk - netlink kernel create(NETLINK TEST, 
n1] data ready); 


skb-alloc skb(NLMSG SPACE(MAX PAYLOAD) , 

5 GFP. KERNEL) ; 

nih - (struct nimsghdr ")skb-sdata; 
n1h-snimsg len - NLMSG SPACE(MAX PAYLOAD); 
n1h-snimsg pid - 0; /" a rendszermagból 7/ 
n1h-:nimsg flags — 0; 

strcpy(NLMSG DATA(n1h), "Greeting from kernel!"); 
/" sender is in group 1-0 7/ 

NETLINK CB(skb).groups — 1; 

NETLINK. CB(skb).pid - 0; /" a rendszermagból "/ 
NETLINK CB(skb).dst pid - 0; /" multicast 7"/ 

/" to mcast group 1-0 "/ 

NETLINK. CB(skb).dst groups — 1; 

/"multicast üzenet minden figyelő folyamatnak "/ 
netlink broadcast(nl sk, skb, 0, 1, GFP KERNEL); 
sock release(ni] sk-ssocket); 


: 


Tételezzük fel, hogy a végrehajtható állományt n1]. recv 
néven fordítottuk le. Indítsuk el két példányban az nl. recv 
programot: 


./n1.recv € 
waiting for message from kernel 
./nl.recv € 
waiting for message from kernel 


Aztán, amikor betöltöttük a rendszermag térben futó kódot 
végrehajtó modult, az n] recv mindkét példánya a követke- 
ző üzenetet kapja: 


Received message payload: Greeting from kernel! 
Received message payload: Greeting from kernel! 


Osszefoglalás 

A Netlink socket rugalmas kommunikációs felületet 
biztosít a felhasználói tér alkalmazásai és a rendszermag 
modulok között. Könnyen kezelhető socket API-val ren- 
delkezik az alkalmazás és a rendszermag oldalán egy- 
aránt. Olyan fejlett kapcsolattartó képességekkel bír, 
mint a full-duplex, pufferelt [/O, és aszinkron kommu- 
nikáció, amelyek más rendszermagffelhasználói-tér 
IPC-kból hiányoznak. 
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Saját nyelvi felület készítése GCC-hez 


Jó hír a nyelvtervezőknek hogy egyszerűbbé vált a nyelvi felületek készítése 


a GCC-hez. 


GCC, ez az elsőrangú ingyenes programfordító 
A készlet, rengeteg változáson ment keresztül az 

utóbbi néhány évben. Az egyik ilyen változás, 
nevezetesen a tree-ssa ág beolvasztása lényegesen leegy- 
szerűsítette az új GCC előtétek készítését. 
A GCC mindig is két belső megvalósítással rendelkezett, 
a fákkal és az RTL-el. Az RTL, azaz regiszter átviteli nyelv, 
az alacsonyabb szintű megoldás, ezt használja a GCC a gépi 
kód készítésekor. Korábban minden optimalizálás az RTL 
szintjén folyt. A fák magasabb szintű megoldások. Hagyo- 
mányosan ezek kevésbé dokumentáltak és kevésbé ismer- 
tek voltak mint az RTL. 
A Diego Novillo vezette, GCC belső részeinek hosszú távú 
újraírását célzó tree-ssa projekt mindezt megváltoztatja. 
A fák azóta sokat fejlődtek, igaz még mindig kicsit hiányosan 
dokumentáltak, viszont sok optimalizálás már a fa szinten 
megtörténik. A munka hasznos mellékterméke a fa alapú 
nyelvek egyértelmű megfogalmazása: a GENERIC. Minden 
GCC nyelvi felület GENERIC-et készít, amelyet később egy 
másik, GIMFLE nevű alacsonyabb szintű fa alapú leírássá 
alakítunk, végül innen lépünk tovább a RTL-re. Ami ebből 
számunkra lényeges, hogy mostantól sokkal, de sokkal 
könnyebb nyelvi felületet írni a GCC-hez. Tulajdonképpen, 
most már akár az is képes GCC nyelvi felületet készíteni, aki 
egyáltalán nem ért az RTL megvalósításokhoz. Ez a cikk vé- 
gigvezet bennünket azokon a lépéseken, melyekkel elkészít- 
hetjük saját fordítóprogramunk GCC felületét. A cikkben leír- 
tak a 2005-ben megjelent GCC 4.0-ás verzióra vonatkoznak. 


A program ábrázolása 

A mi szempontunkból a fordítás két részből áll, értelmezés 
és szemantikai vizsgálat, majd a kódgenerálás. A GCC a má- 
sodik részt elvégzi, így már csak az a kérdés hogyan tudjuk 
a legjobban megvalósítani az első fázist? 

A hagyományos GCC nyelvi felületek, például a C és 

a C4-- felület, értelmezés közben készítik el a fát. Az ilyen 
felületek a nyelv specifikus szerkezetekhez saját fa-kódot 
adnak meg. Aztán amikor a szemantikai vizsgálat befe- 
jeződött, ezeket a fákat GENERIC-é alakítják, a magas 
szintű nyelvspecifikus fákat alacsonyabb szintű változa- 
tokkal helyettesítve. A megközelítés egyik előnye, hogy 

a nyelvspecifikus fák már amúgy is közel GENERIC alakú- 
ak. A szintcsökkentési fázissal gyakran elkerülhető, hogy 
túlságosan sok szemét keletkezzen. 
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A legfőbb probléma ezzel a megközelítéssel, hogy a fa 
dinamikus típusú. Elméletben ez még nem olyan nagy baj, 
hiszen rengeteg dinamikus típusú környezet létezik ame- 
lyeket hatékonyan használhatnak a fejlesztők, például ilyen 
a Lisp és a Python is. Ugyanakkor ezek teljes környezetek, 
a GCC erősen , makrósított" C kódjáról viszont nem lehet 
elmondani ugyanezeket az előnyöket. 
Magam részéről azokat a megközelítéseket kedvelem, ame- 
lyek erősen típusos nyelvspecifikus programábrázolást más 
néven az úgynevezett , abstract syntax tree" (AST) megol- 
dást alkalmazzák. Ezt a megközelítést alkalmazza az Ada 
felület és a Java programozási nyelvhez készült nyelvi felü- 
let újraírt változata, a gcjx. 
A gcjx C4 4 nyelven készült és a java programozási nyelv 
osztályait modellező osztály hierarchiával rendelkezik. 
Ez a kód lényegében független a GCC-től és akár más célra 
is felhasználható. A gcjx esetében például a modellt levihet- 
jük a GENERIC szintjére, de akár használhatjuk bájtkód 
vagy JNI fejlécfájlok előállítására is. Ezen kívül akár kód- 
vizsgálatot is végezhetünk; a felület gyakorlatilag újrahasz- 
nosítható könyvtár lesz. 
Ez a megközelítés az erősen típusos tervezés minden előnyét 
élvezi. A GCC esetében ez konkrétan annyit jelent, hogy 
könnyebben karbantartható és érthető programot kapunk. 
Az eredményül kapott felület és a GCC viszonylagos függet- 
lensége azért is előnyös, mert a GCC igen gyorsan változik 
és ez a laza párosítás minimálisra csökkenti hiba lehetőségét. 
A megközelítés nyilvánvaló hátránya hogy a fordítóprogra- 
munknak valószínűleg több munkát kell végeznie mint 
amennyire szigorúan szüksége lenne, vagy több memóriát 
használ. A gyakorlatban ez nem tűnik igazán fontosnak. 
Mielőtt belevágnánk a GCC felületkészítés részleteinek meg- 
ismerésébe, nézzük meg milyen dokumentációkat és forrás- 
fájlokat érdemes megismernünk. Tekintettel arra, hogy 
a GCC közösség nem tulajdonított túl nagy jelentőséget az 
egyszerűen elkészíthető nyelvi felületnek, néhány fontos 
dolog csak a forrásban van dokumentálva. Az itt felsorolt 
dokumentációk info lapokra és nem URL-ekre hivatkoznak, 
hiszen a GCC 4.0 még nem jött ki. Ezért aztán a weblapokon 
a korábbi verziókat láthatjuk. A legjobb amit tehetünk, hogy 
a CVS-ből letöltjük a GCC-t és átlapozzuk a forráskódot. 
e  gcc/c.opt: leírja a C családba tartozó nyelvi felületek 
parancssori kapcsolóit. És ami még fontosabb bemutatja 
az .opt állományok formátumát. Ilyet kell majd írnunk. 








e  gccinfó lap, Spec Files csomópont (gcc/doc/invoke.texi 
forrásfájl): a GCC meghajtó által használt meghatározó 
mininyelvet írja le. Ilyen meghatározásokat fogunk 
készíteni, amely megmutatja a GCC-nek, hogyan kell 
meghívnia a felületünket. 

e  gccint infó lap, Front End csomópont (gcc/doc/ 
sourcebuild.texi forrásfájl): ismerteti hogyan integráljuk 
a felületünket a GCC fordítási folyamatába. 

e  gccint infó lap, Tree SSA csomópont (gcc/doc/tree-ssa.texi 
forrásfájl): a GENERIC leírása. 

e  gcc/tree.def, gcc/tree.h: a fák néhány olyan jellemzője ami 
úgy tűnik kimaradt a dokumentációkból, ezeket a fájlo- 
kat elolvasva megismerhető. A tree.def definiálja a leg- 
több fa kódot és tartalmaz néhány átfogó megjegyzést. 
A tree.h definiálja a fa szerkezetét, a sok elérési makrót 
valamint néhány függvényt, amelyek a különféle fák 
létrehozása során lehetnek segítségünkre. 

e  libcpp/include/line-map.h: a sortérképet a GCC forráskód 
helyek tárolására használja. Ezt tetszés szerint használ- 
hatjuk a saját nyelvi felületünk megvalósításában. 

A gcjx nem használja. Ha nem is használjuk őket, 

a GENERIC szintjére lépéskor mindenképpen el kell ké- 
szíteni azokat, ugyanis a sortérképben tárolt információ- 
kat használjuk a hibakeresési információk előállításához. 

e  gcc/errors.h, gcc/diagnostic.h: A GCC hibaformázási függ- 
vényeit definiálja ezeket tetszés szerint használhatjuk. 

e  gcc/gdbinit.in: néhány GDB parancsot definiál amelyek 
jól jöhetnek ha hibát keresünk a GCC-ben. Például a pt 
parancs szöveges alakban rajzolja ki a fát. A GCC for- 
dítási könyvtárában készül egy .gdbinit állomány, így 
ha hibát keresünk a makrók azonnal elérhetőek lesznek. 

e  gcc/langhooks.h: a GCC a nyelvi horgok módszerének 
alkalmazásával teszi lehetővé a nyelvi felületeknek, 
hogy a GCC viselkedését befolyásolhassák. Minden fe- 
lületnek saját langhooks struktúrát kell készítenie; Ezek 
a struktúrák lényegében függvénymutatókból állnak. 
A GCC közép és alsó rétege hívja meg ezeket a függvé- 
nyeket ha nyelvfüggő döntetéseket kell hozni a fordí- 
tás folyamán. A langhooks szerkezetek időről időre 
változnak, azonban a GCC olyan módszerrel igényli 
a szerkezetek alaphelyzetbe állítását, hogy ezek 
a változások lényegében nem jelentenek problémát 
forráskód szinten. Néhány nyelvi hurok nem szabadon 
választható, így a felületünkhöz mindenképpen el kell 
készítenünk azokat. Mások ad hoc megoldások egy 
adott problémára. Például, a can use bit fields p 
horog kizárólag a gcj rendszer optimalizálási problé- 
májának megoldása kedvéért került a rendszerbe. 


Meghajtó készítése 

Jelenleg a GCC megköveteli, hogy a felületünk fordításkor 
elérhető legyen. Nem tudunk olyan felületet készíteni amely 
egy már meglévő GCC telepítéshez csatlakozik. Ennél a lé- 
pésnél érdemes elolvasni a vonatkozó GCC kézikönyv olda- 
lakat, hogy megtudjuk hogyan készítsük el a felülethez szük- 
séges fordítási környezetet. Természetesen a legegyszerűbb 
módszer ha egy már meglévő nyelvi felület állományait 
másoljuk át és azt módosítjuk az igényeinknek megfelelően. 
Ezek után két fájlt készítünk el, amelyek segítenek felületün- 
ket a GCC meghajtóprogramba illeszteni. A lang-specs.h állo- 
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mány a felületünket ismerteti a GCC meghajtó számára. Meg- 

mutatja a meghajtónak, hogy amikor ezt a kiterjesztést látja 

a parancssorban a GCC a mi felületünket kell meghívja. Ezen 

kívül az egyéb meghívandó programokkal kapcsolatos infor- 

mációkkal látja el a meghajtót, például kell-e assemblert futtat- 
ni a felületünk után, és hogyan adjunk át vagy módosítsunk 
bizonyos parancssori kapcsolókat. Ennek az állománynak el- 
készítése egy kis időbe telhet hiszen a leírásnak saját különös 
nyelve van. Más nyelvi felületek állományai sokat segíthetnek. 

A lang.opt a felületünkhöz tartozó parancssori kapcsolókat 

mutatják be. Ez az egyszerű szöveges állomány egyértelmű 

formátumot használ. Az egyszerű kapcsolókat például a fi- 
gyelmeztető zászlókat elegendő a lang.opt állományban meg- 
adni és semmilyen további programozást nem igényelnek. 

a többi paramétert általunk írt nyelvi horgoknak kell kezelnie. 

Ezek után készítsük el a fordítás folyamatát vezérlő nyelvi 

horgokat. E csoport legfontosabb elemei: 

e  init options: ez a felületünkhöz intézet első hívás 
a paraméterek feldolgozása előtt. 

e handle option: egy parancssori kapcsoló kezeléséhez 
meghívott horog. 

e post options: a parancssori feldolgozás végeztével 
hívódik meg. Ebben a nyelvi horogban kényelmesen 
meghatározhatjuk az értelmezendő állomány nevét. 

e  init:a post. options után hívódik meg és alaphelyzet- 
be állítja a felületünket. 

e finish: A fordítás végén hívódik meg. Szükség esetén ezt 
használhatjuk a felület utómunkálatainak elvégzéséhez. 

e  parse file: ez a nyelvi horog végzi el a bemeneti 
állományhoz tartozó teljes értelmezést, szemantikai 
vizsgálatot és a kódgenerálást. Lényegében itt történik 
a fordítási munka. 


Alaphelyzetbe állítás 

A GCC elvárja hogy nyelvi felületünk alaphelyzetbe állítsa 
magát. A GCC legtöbb része ön-előkészítő, de a különféle fe- 
lületek igényeihez alkalmazkodva lehetőségünk van néhány 
fákkal kapcsolatos globális változó létrehozására nem típus 
módon. Azért azt javaslom ebbe ne nagyon mélyedjünk bele. 
Sokkal egyszerűbb szabványos módszerrel szabványos fa cso- 
mópontokat definiálni és saját neveket kitalálni a fákhoz ame- 
lyek mondjuk nyelvünk szabványos típusait tartalmazzák. 

Az alaphelyzetbe állítás során esetleg meghívhatjuk 

a build common tree nodes, set sizetype és 

build common tree nodes 2 függvényeket. A set. sizetype 
size t belső megfelelőjének méretét állítja be; a legegysze- 
rűbb ezt mindig long unsigned type node értékre állítani. 
Más beállításokat is végezhetünk ebben a lépésben. A gcjx 
alaphelyzetbe állító kódja például különböző struktúráknak 
megfelelő típusokat hozunk létre amelyek a Java osztályok 
és metódusok leírásához szükségesek. 


Fordítás GENERIC-re 

A parse file nyelvi horog meghívja a fordítónkat, hogy az 
elkészíthesse a belső adatszerkezeteinket. Feltételezve, hogy 
ez hiba nélkül lezajlott, a felületünk készen áll a GENERIC 
fák előállítására saját AST szerkezetünk alapján. A gcjx eseté- 
ben mindez úgy történik, hogy egy különleges ,vendég" 
API-val végiglépkedünk az osztályhoz tartozó AST-on. Az 
API GENERIC-féle megvalósítása lépésenként építi fel a kód- 
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nak megfelelő fákat majd átadja a GCC-nek. A fák elkészíté- 
sének részletes ismertetése már meghaladná cikkünk kerete- 
it. Az alábbi példák azonban bemutatják a három legna- 
gyobb fa típust így megnézhetjük melyik hogyan is néz ki. 


Type 

Ez a fafajta a típusokat adja meg. Nézzünk egy példát 
a gcjx-ből a char Java típusra: 

tree type jchar - make node (CHAR TYPE); 
TYPE. PRECISION (type jchar) - 16; 
fixup.unsigned type (type jchar); 


A fák segítségével bármilyen típust le tudunk írni. Van pél- 
dául rekordokat, uniókat, mutatókat és különféle méretű 
egészeket leíró faszerkezet. 


DecI 
A Dec! az értékadásnak felel meg, avagy más szavakkal egy 
objektumnak adott névnek. Például a forráskódban meg- 
adott helyi változó dec! leírása: 
tree local - build dec] (VAR DECL, get identifier 
5 ("variable name"), 

type jchar); 


A dec1-ek különféle nevesített objektumokat jelenthetnek 
a programban: fordítási egységet (translation unit), függvé- 
nyeket, mezőket, változókat, paramétereket, konstansokat, 


felel meg, szemben magával a típussal. 


Expr 

A programban előforduló különféle kifejezések leírásához 
sokféle expr fa áll rendelkezésünkre. Ezek hasonlóak a C kife- 
jezésekhez, de bizonyos értelemben annál általánosabbak. 

A fák például nem tesznek különbséget az if utasítás és a fel- 
tételes kifejezés között - mindkettőt a COND. EXPR írja le, és az 
egyetlen különbség közöttük annyi, hogy az if utasítás void 
típusú. A következő kifejezés önmagát adja egy változóhoz: 
tree addition - build2 (PLUS EXPR, type jchar, 
local, local); 


Az utasításoknak megfelelő fákat egy különleges közelítő 
API csatolja egymáshoz. Két utasítást (51 és 52) a következő- 
képpen csatolhatjuk egymáshoz: 

tree result - alloc stmt list O; 

tree stmt iterator out — tsi start (result); 

tsi link after (§out, s1, TSI CONTINUE LINKING); 
tsi link after (gout, s2, TSI CONTINUE LINKING); 

// most a "result"-ba az utasítások listája került. 


Más facsomópontok is léteznek; minden megtalálunk 

a tree.def állományban és a kézikönyvoldalon. A felületek sa- 
ját fakódot is meghatározhatnak; azonban ha saját AST-nk 
van erre nem lesz szükségünk. A készülő program teljes szer- 
kezete valószínűleg a dec! fordítási egységre hasonlít majd, 
amely típusokat, változókat és függvényeket tartalmaz. 


Átadás 
Miután elkészítettük a függvényt, globális változót vagy tí- 
pust leíró fát, amelyhez hibakeresési információt szeretnénk 
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készíteni, a fát át kell adnunk a megfelelő függvénynek amely 
elvégzi a fordítás maradék részét. Jelenleg három ilyen függ- 
vény létezik: rest. of. decI. compilation a dec] csomópont 
fordítását végzi el, a cgraph finalize function a függvé- 
nyek fordítását kezeli és a rest. of. type compilation a típu- 
sok fordításával foglalkozik. 


Hibakeresés 

Bár a GCC-ben szép számmal találunk belső konzisztencia 
ellenőrzési pontokat, még így is elég könnyű összeomlást 
produkálni a felületünktől idegen kóddal. A legtöbb össze- 
omlás esetén végiglépdelhetünk a vermen és megnézhetjük 
milyen fák voltak módosítva, amíg meg nem találjuk a hibás 
fakészítés okozta hibát. Ehhez a módszerhez meglepően ke- 
vés általános GCC ismeret is elegendő, így is hatékonyan tu- 
dunk hibákat keresni a kódban. A GCC rendelkezik néhány 
kézreálló hibakeresési lehetőséggel. A hibakeresőben meg- 
hívhatjuk a debug tree függvényt, amely kinyomtatja a fát. 
Az -fdump-tree parancssori kapcsolócsaláddal adott számú 
menet után is kiírathatjuk a fák értékét. 


Tapasztalatok 

A gcjx írása során szerzett tapasztalataim szerint az erősen 
típusos köztes megfelelő átalakítása fákká igen egyszerű 
volt. A gcjx fa háttérkódja, egy háttérkód a sok közül, a teljes 
fordító kódjának mintegy 1096-át teszi ki. Bár még befejezet- 
len körülbelül 6,000 kódsorból áll (nyers wc -1 számlálás 
alapján) körülbelül akkora mint a bájtkód háttér. Ebből le 
lehet vonni azt a következtetést, hogy ha a fordítóprogra- 
munk már készen van a GCC-hez kapcsolása már könnye- 
dén megvalósítható. Tekintve, hogy a fák magas szintűek, 
egyetlen RTL-t sem néztem mgg a felület készítése során és 
egyáltalán semmi időt nem kellett eltöltenem azzal, hogy 
processzor-specifikus problémákon törjem a fejemet. 
Amennyiben a nyelvnek amit választottál nincsenek külön- 
leges követelményei, veled is hasonló lesz a helyzet. 

A gejx statikusan típusos AST-je könnyedén újrahasznosít- 
ható. Jelenleg négy háttér létezik és valószínűleg többet is 
írok később. Például nem lenne nehéz például olyan hátte- 
ret készíteni, amely a program kereszthivatkozásait menti 
adatbázisba. Vagy írhatnánk olyan hátteret amely végiglép- 
ked az AST-n és kikeresi a tipikus hibákat, a FindBugs prog- 
ramhoz hasonlóan. Ez az elgondolás még ösztönzőbb lehet 
olyan nyelvek esetében amelyek, a Javaval ellentétben, 
nem rendelkeznek gazdag analizáló készletekkel. 


Jövőbeli elképzelések 

A felületek írása természetesen lehetne még ennél is egy- 
szerűbb. Például nincs szükség a lang-specs.h beillesztésére. 
Ehelyett a nyelvi felület telepíthetne egy leíróállományt, 
amit a GCC meghajtó induláskor beolvasna. Hasonlókép- 
pen a lang.opt is elhagyható lenne. Egy kis munkával idő- 
vel talán az is elérhető, hogy a GCC-től függetlenül tudjunk 
nyelvi felületeket fordítani. 


A cikk forrásai: www.linuxjournal.comj/article/8138 
Linux Journal 2005. május, 133. szám 


Tom Tromey 








CGI programozás C nyelven 


Az összetett webes feladatok elvégzését a CGI egyszerűségének megőrzése mellett 
is felgyorsíthatjuk. A rengeteg hasznos könyvtárnak köszönhetően a parancsfájl- 
készítő nyelvekről C-re áttérni nem is olyan nagy ugrás, mint azt gondolnánk. 


Perl, a Python és a PHP alkotja a CGI alkalma- 
A zásprogramozás szentháromságát. A boltok pol- 

cai roskadoznak az ezekről a nyelvekről szóló 
könyvektől, a számítástechnikai sajtó úton-útfélen velük 
foglalkozik, ahogy számos internetes fórumnak is ezek 
adják a témáját. Szembetűnő ugyanakkor, hogy mennyire 
nem érdekel senkit a C alapú CGI alkalmazások írása. 
Írásomban éppen ezért a C nyelv CGI programozásra 
való használatát fogom tárgyalni, valamint ismertetek 
néhány olyan helyzetet, amelyben alkalmazása számot- 
tevő előnyökkel jár. 
Én három ok miatt használok C-t az alkalmazásaimban: 
gyors, nagy tudású és stabil. Bár a szághagyomány más- 
képp sugallja, saját méréseim alapján egyszerűbb felada- 
tok végrehajtásakor a C és a PHP sebessége azonos, ami- 
kor pedig a feladat bonyolultabbá válik, a C lehengerlő 
győzelmet arat. 
A C emellett rendkívül nagy tudású nyelv. Maga a nyelv 
ugyan csak egyfajta váznak mondható, ám az elérhető 
könyvtárak hihetetlenül széles választékával szinte min- 
dent meg tudunk oldani, amire csak egy számítógép alkal- 
mas lehet. Természetesen a Perl sem kezdő játékos ezen 
a területen, és egy pillanatig sem vitatom, hogy mindkét 
nyelv rendkívüli sokoldalúságot kínál használójának; 
bár szerintem a C könnyebben bővíthető. 
Továbbá, a C-ben írt CGI programok üzembiztosabbak. 
Mivel a program teljes egészében lefordításra kerül, nem 
érzékeny az operációs rendszer által biztosított környezet 
megváltozásaira, ahogy például a PHP. Maga a nyelv is ál- 
landónak tekinthető, esetében nem kell olyan gyökeres vál- 
tozásokkal számolni, mint amilyenek a PHP használóinak 
idegeit borzolták az elmúlt években. 


Az alkalmazás 

Alkalmazásom egy egyszerű eseménylista, a jövőbeli ese- 
mények kezelésére, például üzleti megbeszélések időpont- 
jának rögzítésére vagy akár egy templom eseményeinek 
ütemezésére használható. Rendelkezik egy — szándékom 
szerint — jelszóval védett felügyeleti felülettel, valamint egy 
nyilvános felülettel is, amely — kizárólag — a közeljövő ese- 
ményeit listázza ki. Az alkalmazás felületfüggetlen, beállítá- 
sai futás közben módosíthatók. 
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1. kódrészlet MySOL séma 


CREATE TABLE event ( 
event no int(11) NOT NULL auto. increment, 
event begin date NOT NULL default "0000-00-00", 
name varchar(80) NOT NULL default "", 
location varchar(80) NOT NULL default "7", 
begin hour varchar(10) default NULL, 
end hour varchar(10) default NULL, 
event end date NOT NULL default "0000-00-00", 
PRIMARY KEY (event no), 
KEY event date (event begin) 


Nem írtam saját adattárat, inkább adatbázist használok, 

a hozzá való csatlakozáshoz szükséges adatokat egy beállító 
fájlba helyezem el. A felület és a kód szétválasztását külön- 
álló fájlcsoporttal biztosítom. 

A felügyeleti felület alkalmas az események listázására, 
szerkesztésére, mentésére és törlésére. Az események listá- 
zása az alapművelet, amennyiben más műveletet nem vá- 
lasztunk ki. Az új és a meglévő eseményeket egyaránt lehet 
menteni. A felület tartalmaz egy rácsozatot, ebben jelenik 
meg az eseménylista, valamint egy részletes képernyőt, 
amin egy-egy esemény részletei is megtekinthetők. 

Az alkalmazás adatbázissémája egyetlen táblából áll, ezt 

az 1. kódrészlettel adjuk meg. Az alábbi séma MySOL-hez 
készült, de természetesen bármilyen adatbázismotorhoz 
megírható egy ilyen kódrészlet. 

A következő függvényekre mindenképpen szükség van 

a felügyeleti felület által biztosított szolgáltatások megvaló- 
sításához: list. events), show event), save. event) és 
delete event) (rendre események listázása, megjeleníté- 
se, mentése és törlése). Az adatbázis olvasását és írását is 
külön függvénycsoportba fogom elvonatkoztatni, így az 
egyes függvények egyszerűbbek maradnak, és egyszerűbb 
a hibakeresés is. Az adattároló felülethez a következő függ- 
vények szükségesek: event. create(), event. destroyO, 
event. readO, event write és event. delete (esemény lét- 
rehozása, megsemmisítése, olvasása, írása és törlése). Mivel 
minden lehetőséget megragadok, hogy megkönnyítsem az 
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2. kódrészlet A beállítások futás közbeni megadását 
lehetővé tévő függvény 


void config read(char" filename, char"" key, 
char"" value) í 
FILE" cfile; 
char tok[80]; 
char line[2048]; 
char" target; 
ant as 
int length; 
cfile - fopen(filename, "r"); 
16 (VeFrile 
perror("config. read") ; 
return; 
$ 
while(fgets(Iine, 2048, cfile)) ( 
ür (targetessereheülüne sz )9)DEt 
sscanf(Iine, "480s"7, tok); 
forCi-O0; keyl[lil; ir4) ( 
me téstrempikey Hi Nő Etok 0) Et 
IGE EESE 
whileCisspace("target)) targett-i; 
length - strlen(target) ; 
value[ti] - (char")calloc(i, length 1; 
strcpy(value[lil], target); 
target - €value[lill[llength - 1]; 
while(Cisspace("target)) "target- - 0; 
1 
3 
a 
3 
fclose(cfile); 
: 


életemet, készítek egy event. fetch range) (eseménytar- 
tomány lekérdezése) függvényt is, amivel adott tartomány- 
ba eső eseményeket tudok kiválasztani. Erre legalább két 
helyen szükség lesz. 

Következőként a rekordjaimat C adatszerkezeteknek, az 
adatbázis-lekérdezések eredményeit pedig láncolt listáknak 
kell megfeleltetnem. Az elvonatkoztatás lehetővé teszi, 
hogy - mivel a kódnak csak kis része foglalkozik közvetle- 
nül az adattárolóval — viszonylag kis fáradság árán le tud- 
jam cserélni az adatbázismotort, vagy meg tudjam változ- 
tatni az adatábrázolás módját. 

A teljes forráskódot természetesen nyomtatásban nem 
jelentethetjük meg, ezért a Makefile társaságában a web- 
oldalamról lehet letölteni (lásd az internetes forrásokat). 


Eszközök 

C használatakor az első leküzdendő akadály a szükséges 
eszközök beszerzése. Minimálisan egy CGI-feldolgozóra 
szükségünk lesz, ez fogja elérhetővé tenni számunkra 

a CGI adatait. Nagy valószínűséggel valamilyen adatbázis- 
kapcsolat is jól jön. Nem árt, ha a vezérlő logikát és a felüle- 
tet valamilyen szinten szét tudjuk választani, így ugyanis az 
oldal átdolgozása nem jár a kód újabb és újabb újraírásával. 
CGI feldolgozási célokra Thomas Boutell cgic könyvtárát 
ajánlom (lásd a forrásokat). Használata megdöbbentően 
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3. kódrészlet HTML sablonfüggvény 


void html get(char" path, char" file) ( 
struct stat sb; 
FILE?" html; 
char" buffer; 
char fullpath[10241]; 
/: A fájl és az elérési út neve túllép a rendszer 
s korlátján "/ 
if (strlen(path) -4 strlen(file) 5 1024) return; 
sprintf(fullpath, "95/9657, path, file); 
if (stat(fullpath, €s5b)) return; 
buffer - (char")calloc(i, sb.st.size 4 1; 
if (!buffer) return; 
htm] - fopen(fullpath, "r"); 
fread((void")buffer, 1, sb.st size, html); 
fclose(htm1); 
puts (buffer) ; 
free(buffer) ; 


egyszerű, és a CGI felület minden részéhez elérést biztosít. 
Ha inkább C-t-- irányultságúak vagyunk, a cgicc könyvtá- 
rakat használhatjuk (lásd a forrásokat). Szerintem a Boutell 
könyvtárral könnyebb dolgozni. 

A MYySOL a UNCX alapú webes fejlesztéseknél gyakorlatilag 
szabványnak tekinthető, ezért ebben az esetben én is nála 
maradok. Minden komolyabb adatbázismotornak van C fe- 
lületkönyvtára, vagyis mindenki olyan adatbázist választ, 
amilyet csak szeretne. 

Jómagam elkészítem a saját felületfüggetlen eljárásaimat, 
de aki úgy gondolja, a libxml és a libxslt segítségével 
ugyanezt jóval kifinomultabb szinten oldhatja meg. 


Futás közben megadott beállítások 

Fontos tényező, hogy az adatbázis-kapcsolat beállításait futás 
közben is meg lehessen adni. A beállító függvény egy fájlnév 
és egy a beállító kulcsokat megadó karakterlánctömb alapján 
feltölt egy tömböt a megfelelő beállítási értékekkel. (Lásd 

a 2. kódrészletet.) Ezután tetszőleges, az általam kiválasztott 
kulcsokkal tölthetek fel egy megfelelő karakterlánctömböt, 
az eredményt az értéktömbben kapom meg. 


A felhasználói felület 

A felhasználói felület két részből áll. Én, mint programozó, 
elsősorban a beviteli űrlapokkal és az URL-karakterláncok- 
kal foglalkozom. Mindenki más inkább arra figyel, hogy 

az űrlapomat körülvevő oldal hogyan néz ki, magát az 
űrlapot adottnak veszi. Ha mindkét fél elégedettségét bizto- 
sítani akarjuk, akkor külön kell választanunk az oldalt az 
űrlaptól és a programtól. 

PHP és Perl alá számtalan sablonkönyvtár létezik, ám C alá 
nem nagyon találunk HTML sablonokat. A legjobb az, ha 

a C kód a kimenetnek csak a lehető legkisebb részét foglalja 
magába, a maradékot pedig HTML formátumú fájlokba he- 
lyezzük el, melyeket mindig a megfelelő időpontban jelení- 
tünk meg. Erre alkalmas függvényt látunk a 3. kódrészletben. 
A kimenet kiadása előtt közölnünk kell a webkiszolgálóval 
és a böngészővel, hogy mit is szeretnénk átadni; 

a cgiHeaderContentType() pontosan ezt a célt szolgálja. 








. kódrészlet se 


ruct event? e; 


eze 
cgiF ev 
cgiFormStringNoNewline 


ormStringNoNew 





A tartalom típusa (content type) text/html, ezért ezt hasz- 
nálom átadott értékként. Minden oldal megjelenítése előtt 
az alábbi általános lépéseket kell követnünk: 


cgiHeaderContentType("text/htm1") ; 
html. get(path, pagetop.htm1); 

A tartalom előállítása. 

html. get(path, pagebottom.htm1); 


Az űrlapok feldolyozása 

Megoldottuk az oldalak és az űrlapok megjelenítését, most te- 
hát gondoskodnunk kell az űrlap tartalmának feldolgozásáról. 
Numerikus és szöveges elemek beolvasására egyaránt szükség 
lehet, ezért a cgic könyvtár két függvényét veszem igénybe, 
ezek a cgiFormstringNoNewlines () és a cgiForminteger (). 
A cgic könyvtár tartalmazza a fő függvény megvalósítását, 
rám csak az int cgiMain(void) — túlnyomó részt ebben törté- 
nik az űrlap feldolgozása — megírásának feladata hárul. 

Ha a show. event függvénnyel egyetlen rekordot akarok 
megjeleníteni, akkor a CGI eventno átadott érték event no 
(ez az elsődleges kulcs) értékét veszem. 

A cgiFormintegerO függvény egy egész értéket kérdez le, 
és ha nincs megadva CGI átadott érték, akkor alapértelme- 
zettet állít be. 

A save. event szintén jó néhány adatot igényel az űrlapból. 
A dátumok bevitele fogas kérdés, ugyanis három adatrész- 
ből állnak: évből, hónapból és napból. Kezdő és záró dá- 
tumra egyaránt szükség van, vagyis összesen hat mező tar- 
talmát kell feldolgozni. Szükség van még az esemény nevé- 
re, kezdő és záró időpontjára (ezek karakterláncok, ugyanis 
önmagukban is lehetnek események, mint például napkelte 
és napnyugta) és helyére. A 4. kódrészlet mindennek a meg- 
valósítását szemlélteti. 
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int result; 
giFormselectSsingle 





A 4. kódrészletben a cgiHeaderLocation() is szerepel, 
ennek feladata a felhasználó új oldalra irányítása. Miután 
elmentettem az elküldött adatokat, mindig az eseménylista 
oldalt szeretném megjeleníteni. Meghatározott karakter- 
lánc helyett a libcgic által biztosított változók egyikét, 

a cgiScriptName-et használom, ezzel azt érem el, hogy 

a program neve működésének megzavarása nélkül meg- 
változtatható. 

Végül kell valamilyen megoldás az adatok elküldésére 
szolgáló (submit) gombok kezelésére. Ezek a legösszetet- 
tebb beviteli megoldások, az elindítandó függvény ugyanis 
esetükben az értéküktől függ, illetve szükség esetén alapér- 
telmezett értéket is kell választani. A cgic könyvtárnak van 
egy függvénye, a cgiFormselectsingleO, amely pontosan 
ezt végzi el. Működéséhez a lehetséges értékeknek egy 
karakterlánctömbben kell szerepelniük. Egy egész értékbe 
helyezi a megfelelő átadott érték tömbbeli indexét; ha pedig 
nem talál egyezést, akkor az alapértéket használja. 

A függvénymutatókról bővebb tájékoztatás a források kö- 
zött található. Aki nem békült még meg a függvénymuta- 
tókkal, az switch utasítással is megoldhatja mindezt. Jóma- 
gam inkább a függvénymutatókat szeretem, ez a megoldás 
ugyanis tömörebb; régebbi kódjaimban ugyanakkor termé- 
szetesen a switch utasítást is használtam. 


Az atatbázisrendszer 

A MYSOL kezelése C alól nagyon hasonló a PHP alóli keze- 
léshez — már amennyiben ez mond valamit. A karakterlán- 
cokban szereplő problémás karakterek, például a kettős idé- 
zőjelek és a visszaperjelek eltávolítására a MySOL megfelelő 
függvényeit kell használnunk, de más eltérést nem nagyon 
fogunk találni. A show event() függvény esetében az elsőd- 
leges kulcs alapján kell lekérdeznünk egy rekordot. A hiba- 
kezelés miatt a kód meghízik ugyan, de három alaputasítás 
adja a lényeget. A mysg]. gueryO hívásakor lefut a MySOL 
utasítás, aminek keletkezik valamilyen eredménye. Ezután 
a mysgl. store resultO lekérdezi az eredménykészletet 

a kiszolgálótól. Végül a mysagl. fetch rowO egyetlen 

MYSOL Row változót emel ki az eredménykészletből. 

A MYSOL Row változót karakterláncok tömbjeként (char"") 
kezelhetjük. Ha az adatok valamelyike numerikus, és nume- 
rikusként is szeretnénk használni, akkor át kell alakítanunk. 
Jelenlegi programunkban például a dátumot három külön- 
álló számérték formájában érdemes kezelni. Mivel a ka- 
pott adat ÉÉÉÉ-HH-NN szerkezetű, a sscanf ) függ- 
vénnyel választhatjuk szét az összetevőit. (6. kódrészlet) 

Az adatok adatbázisba írása érdekesebb, itt ugyanis 

ügyelni kell a problémás karakterek kiszűrésére. 

Ezt a 7. kódrészlet szemlélteti. 
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MYSOL ROW row; 
int begi 
int be 


ear; 





Az escapedname ugyanazt a karakterláncot tartalmazza, 
mint a name, de a MySOL különleges karakterei nélkül; így 
már nyugodtan beilleszthetjük egy SOL-utasításba. Fontos, 
hogy a felhasználók által megadott karakterláncokat min- 
dig tisztítsuk meg, ellenkező esetben rosszindulatú szemé- 
lyek kihasználhatják hanyagságunkat, és kellemetlen dol- 
gokat művelhetnek az adatbázisunkkal. 


CGI programok hibakeresése 

A C programok hibáinak felderítése elég kellemetlen tevé- 
kenység, ugyanis általában szegmentációs hibát okoznak, 
és semmilyen jelzést nem kapunk a hiba forrásáról. A hiba- 
kereső programok más alkalmazások esetében kiválóan 
megfelelnek, ám a CGI programoknál a bemenő adatok 
fogadásának módja miatt más a helyzet. 

Ilyenkor siet segítségünkre a cgic könyvtárban található 
capture nevű CGI program, mely a neki küldött CGI- 
bemeneteket egy fájlba rögzíti. A fájl nevét a capture for- 
ráskódjában adhatjuk meg. Ha CGI programunkon hibake- 
resést kell végeznünk, akkor cgiMainO) függvényének ele- 
jére adjunk hozzá egy cgiReadEnvi ronment(char") hívást. 
Ügyeljünk arra, hogy a filename átadott érték megegyez- 
zen a rögzítéshez megadottal. Ezután a problémás adatot 

a kérésünkben szereplő űrlap vagy parancsfájl alapértelme- 
zett műveletévé téve küldhetjük el rögzítésre. Végül 

a GDB-vel vagy kedvenc hibakeresőnkkel bogozhatjuk ki, 
hogy kódunk pontosan milyen hibát okozott. 

A későbbi hibakeresést és fejlesztést bizonyos lépések- 
kel leegyszerűsíthetjük. Bár ezek minden program fejlesz- 
tésére érvényesek, CGI programozásnál különösen kifize- 
tődők. Ne feledjük, egy-egy függvénynek egyetlen, és 
csakis egyetlen feladatot adjunk, továbbá tesztelését 
minél hamarabb kezdjük el, és a lehető leggyakrabban 
ismételjük meg. 

A kód írása közben érdemes minden egyes függvényt azon- 
nal kipróbálni, és ellenőrizni, hogy valóban a tőle elvárt mó- 
don működik-e. Azt is érdemes megvizsgálni, hogy hibás 
adatok megadására hogyan válaszol, ugyanis nagyon való- 
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7. kódrészlet A fel 





színű, hogy élete során a függvény előbb-utóbb valóban 
fog hibás adatokat kapni. Ha minderre jó előre gondolunk, 
akkor sok kellemetlenséget spórolhatunk meg magunknak. 


Telepítés 

A fejlesztésre és a futtatásra használt számítógép az esetek 
nagy részében nem ugyanaz. A fejlesztői rendszert ezért 
próbáljuk a lehető legnagyobb mértékben azonossá tenni 

a termelési rendszerrel. Én például a programjaimat általá- 
ban Linux vagy OpenBSD alatt fejlesztem, futtatásuk vi- 
szont szinte mindig FreeBSD alatt történik. 

Amikor felkészülünk a termelési rendszer felépítésére vagy 
telepítésére, akkor különösen fontos, hogy tisztában le- 
gyünk a könyvtárváltozatok közötti különbségekkel. Azt, 
hogy kódunk mely dinamikus könyvtárakat használja, az 
1dd paranccsal tekinthetjük meg. Érdemes ellenőrizni, mert 
meglepetéseket okozhatnak a könyvtárak miatt felmerülő 
további függőségek. 

Ha a könyvtárváltozatok közel állnak egymáshoz, ami álta- 
lában a fő változatszámok megegyezésében nyilvánul meg, 
akkor különösebb gondokra nem kell számítanunk. A külső 
üzemeltetésű weboldalra telepített programoknál gyakori 
a fejlesztői és a termelési rendszer által tartalmazott válto- 
zatok eltérése. 

Ilyenkor én saját, helyi változatot szoktam fordítani 

a könyvtárból. Eltávolítom a könyvtár megosztott változa- 
tát, és a rendszer által tartalmazott helyett a helyi változatot 
építem be. Természetesen ilyenkor a futtatható fájl megnő, 
ám a fennhatóságunkon kívüli könyvtáraktól való függése 
is megszűnik. 

Miután lefordítottuk a futtatható fájlt a termelési rendsze- 
ren, az 1dd ismételt kiadásával ellenőrizzük, hogy az összes 
dinamikus könyvtár megtalálható-e. A könyvtárak helyi 
változatainak beépítésekor különösen gyakran fordul elő, 
hogy elfeledkezünk a dinamikus változat eltávolításáról, 
amit persze futás közben nem fog találni a program (és az 
1dd). A fordítást sose kapkodjuk el, újra és újra fordítsunk 
és ellenőrizzünk, míg végül el nem tűnnek a könyvtárak 
megtalálásával kapcsolatos hibák. 


Sebesség: CGI kontra PHP 

Általános nézet, hogy a CGI felületet használó programok 
lassabbak, mint a valamilyen kiszolgáló modul — mint 

a mod php és a mod perl — által biztosított nyelvet használók. 
Mivel a webes alkalmazások fejlesztését PHP-ben kezdtem, 
ezt fogom a C-ben írt CGI-k sebességének vizsgálatakor kiin- 
dulási alapként venni. Nyilván mindebből a C és a Perl kö- 
zötti sebességkülönbségekre nézve nem következik semmi. 
Az összehasonlításnál a külső adatbázis-felületet vettem 
(events . cgi és events . php), ugyanis mindkettő azonos 








eljárást alkalmaz a felület elkülönítésére. A belső felületet 
nem teszteltem, ugyanis a külső hívások mellett a belsők 
szerepe szinte elenyésző. 

Az Apache Benchmark segítségével mindkét változatot tíz- 
ezer lekérdezéssel terheltem le, amilyen gyorsan a kiszolgá- 
ló képes volt azokat kezelni. A C alapú változat átlagos vég- 
rehajtási ideje 581 ms, a PHP alapú változaté pedig 601 ms 
volt. Mivel a két érték közel esett egymáshoz, feltételeztem, 
hogy a méréseket megismételve némi szórást észlelek majd. 
Így is volt, de végeredményként elmondhatom, hogy a C 
alapú változat az esetek nagyobb hányadában volt gyor- 
sabb a PHP alapúnál. 

Munkáim során egy összetettebb felületelválasztó könyvtá- 
rat használok, ez a libtemplate (lásd a forrásokat). A könyv- 
tárból PHP és C változat egyaránt létezik. Amikor az ese- 
ményütemező változatait a libtemplate segítségével hasonlí- 
tottam össze, akkor a C alapú változat határozottan jobb vá- 
laszidőkkel futott. A C alapú változat átlagos futási ideje 625 
ms volt; nem sokkal több, mint az egyszerűbb változaté. 

A PHP alapú változat átlagos futási idejére 1957 ms-ot kap- 
tam. Azt is érdemes megjegyezni, hogy a terhelés a PHP 
alapú változat futása közben a C alapú változat futásakor 
mértnek nagyjából kétszerese volt. A tesztek végrehajtása 
közben más komolyabb alkalmazás nem futott a gépen, és 
más felhasználók sem terhelték. 

A két C alapú változat egymáshoz közeli futtatási ideje ar- 
ra utal, hogy az idő nagy része a program betöltésével telik. 
Ha ez megtörtént, a futtatás már gyorsan megy. A PHP 
ezzel szemben viszonylag lassan fut. Természetesen a PHP 







esetében is be kell tölteni a programot a memóriába, ám 
itt a fordítást — amelyen a C alapú program már túlesett — 
is el kell végezni. 


Összefoglalás 

Megfelelő eszközökkel és némi tapasztalattal a C alapú CGI 
alkalmazások fejlesztése nem nehezebb, mint a Perl vagy 
PHP alapúaké. Jómagam mindkettővel rendelkezem, és 
egyértelműen a C-t választottam a CGI-k fejlesztésére. 

A C előnyei főként bonyolultabb műveletek elvégzésekor és 
a hosszú távú stabilitás terén mutatkoznak meg. A PHP-val 
szemben teljesen érzéketlen a kiszolgálót érintő változások- 
ra. Hacsak nem töröljük a gépről valamelyik megosztott 
könyvtárat, például a libc-t vagy libmnysglclientet, a C alapú 
változatot rendkívül nehéz tönkretenni. A C alapú progra- 
mok futásuk gyorsasága miatt összetettebb adatfeldolgozó 
műveletek végrehajtásakor egyértelműen jobb választásnak 
bizonyulnak. 


Linux Journal 2005. április, 132. szám 

A cikk forrásai: 5 www.linuxjournal.comjarticle/8058 
Clay Dowling a Lazarus Internet Development 
(wwwvv.lazarusid.com) elnöke. A programozás 


mellett hobbija a sörfőzés és a borkészítés. 
A clayeolazarusid.com címen érhető el. 
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Sguid alapú forgalomszabályozó 


és felügyeleti rendszer 


Amikor a hálózatunkon folyó forgalom túlnyomó része webes forgalom lett, 
egyetemünk a nyílt forrású Sguid gyorsítótárazó programra építve üzembe 
helyezett egy a hozzáférések követésére és korlátozására alkalmas rendszert. 


ármilyen szervezet számítógépes hálózatáról is 
B legyen szó, az internetelérés az egyik legfonto- 

sabb és leginkább igényelt szolgáltatás. Olifer 
és Olifer a Computer Networks: Principles, Technologies 
and Protocols című könyvükben azt írják, hogy az el- 
múlt 10-15 évben a 80/20-as arány a belső és a kimenő 
forgalom között megfordult, és jelenleg a forgalom 
80 százaléka kifelé irányul (lásd az internetes forráso- 
kat). A hozzáférés sebessége, a szolgáltatások száma 
és a rendelkezésünkre álló tartalom mennyisége folya- 
matosan növekedik. Az interneteléréshez fűződő 
felhasználói hozzáférés-vezérlés kérdése ezzel párhu- 
zamosan egyre fontosabbá válik. Maga a probléma 
természetesen nem új, ám bizonyos vonatkozásai az 
idők során megváltoztak. Írásunkban az elérhető kor- 
szerű megoldásokat tekintjük át, példaként a Bashkir 
State Pedagogical University (Baskíri Állami Pedagógiai 
Egyetem, BSPU) hálózatát véve. 
Elsőként határozzuk meg az internet elérését szabá- 
lyozó és felügyelő rendszerrel szemben támasztott 
elvárásokat: 


e Felhasználói fiókok támogatása 
és kezelése 


e — Felhasználói forgalom számlázása 
és szabályozása 


e Háromféle mód a felhasználói forgalom szabályozására: 
havi, heti és napi 

e A mozgó felhasználók támogatása 
(ők az egyes alkalmakkor különböző számító- 
gépeket használnak az internet elérésére; ilyenek 


például a hallgatók) 


e Napi és heti kimutatások a rendszer állapotáról, 
jelentések a webes és elektronikus levélforgalomról 


e Web alapú kimutatások és rendszerfelügyelet 
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Láthatóan mindezek az elvárások semmilyen módon 
nem hatnak ki a rendszer megvalósításának fázisára, 
vagyis képzeletünknek sem jelentenek korlátokat. 

A problémát tehát általános jelleggel szemléltük, majd 
kidolgoztuk a megoldását. Írásunk további részeiben 

a végső döntésünk felé vezető ötleteket és megfontolá- 
sokat ismertetjük. 


A kérdéskör általános elemzése 

A legnépszerűbb szolgáltatás, a World Wide Web (WWwW) 
példáján röviden tekintsük át, hogy az internetelérés folya- 
mata milyen lépésekből áll: 


1. A felhasználó elindítja aböngészőprogramot, 
majd beírja a kívánt URL-t. 


2. A böngésző vagy közvetlen kapcsolatot létesít 
a WWW-kiszolgálóval az átjárón keresztül, 
utóbbi akár címfordítást vagy más csomagmani- 
pulációs műveletet is végezhet, vagy proxykiszol- 
gálón keresztül csatlakozik, mely gondosan elemzi 
az ügyfél kérését és ellenőrzi, hogy a kért adatok 
szerepelnek-e a gyorsítótárában. Ha nem rendelke- 
zik a kért adatokkal, esetleg azok elavultak, akkor 
a proxykiszolgáló a saját nevében kapcsolódik 
a WWW-kiszolgálóhoz. 


3. A kapott adatokat megkapja az ügyfél. 


4. A böngészőprogram lezárja vagy ébrenléti állapotba 
állítja a kapcsolatot. 


Az 1. ábrán az internetelérés folyamatát szemléltettük. 

A folyamat fő résztvevői a felhasználó, az ügyfélprog- 
ram (böngésző és operációs rendszer), a munkaállomás 
vagy egyéb ügyfélhardver, a hálózati eszközök és az átjá- 
ró vagy proxykiszolgáló. A hálózatra további, például 
felhasználóhitelesítést végző kiszolgálók is csatlakozhat- 
nak, például Microsoft Windows tartományvezérlők, 
OpenLDAP- vagy NIS-kiszolgálók. 














Átjáró 


Hálózat 


Munka- 
állomás 


Böngésző 





Felhasználó 








1. ábra A felhasználók internetelérésének folyamata 


Mint az 1. ábra is szemlélteti, a felhasználók és a munkaál- 
lomások között egy-egy és több-több megfeleltetés egyaránt 
lehet. Az egyetem munkatársai például a legtöbb esetben 
saját számítógéppel rendelkeznek. 

Elsődleges céljaink a felhasználói forgalom számlázása, 

a felhasználók hitelesítése, a felhasználók hozzáférésének 
ellenőrzése, a felügyelet és jelentések készítése. 

Ezek a célok egymástól nagymértékben függetlenek, 

és mindegyiket többféle módon is el lehet érni. A hite- 
lesítés, a forgalomszámlázás és a hozzáférés-vezérlés 
feladata a fenti séma elemeinek bármelyikéhez hozzá- 
rendelhető, a legjobb megoldás azonban kétségtelenül 
az lenne, ha az összes feladat elvégzése egyetlen helyen 
összpontosulna. 

A hozzáférés-vezérlés ügyfél- és kiszolgálóoldalon 
egyaránt megvalósítható. Az ügyféloldali hozzáfé- 
résvezérlés különleges, a felhasználók hitelesítésére 

is képes ügyfélprogram használatát teszi szükségessé. 

A hozzáférés-vezérlés kiszolgálóoldali megvalósításának 
kétféle módja van: tűzfal vagy proxykiszolgáló alkalma- 
zása. A tűzfal alapú megoldás nem alkalmas a felhasz- 
nálók hitelesítésére, hiszen a hálózati csomagok csak 
IP-címeket tartalmaznak, amelyek semmilyen módon 
nem kötődnek a felhasználónevekhez. Ha tűzfalat aka- 
runk használni, akkor erre kétféle megoldás kínálkozik: 
saját felhasználóhitelesítést alkalmazó VPN használata 
vagy dinamikus felhasználó/IP-cím hozzárendelések 
megadása. Ezeket a megoldásokat külső eszközökkel 
valósíthatjuk meg. 

A legegyszerűbb megoldás mégis egy proxykiszolgáló 
használata, mely képes a böngészőn keresztül végzett 
felhasználóhitelesítésre. A böngésző alapú hitelesítésnek 
háromféle módszere létezik: 


e — Alapszintű hitelesítés — Egyszerű és széles körben 
alkalmazott megoldás, melyet az internetes böngészők 
és proxykiszolgálók túlnyomó része támogat. Fő hátrá- 
nya, hogy a felhasználó jelszava a hálózaton keresztül 
titkosítatlanul kerül továbbításra. 


e  Arkivonat alapú hitelesítés egy megbízhatóbb megoldás, 
hátránya a szoftveres támogatás hiánya. 


www.linuxvilag.hu 


e Az NTLM alapú hitelesítés csak a Microsoft ter- 
mékekre épülő hálózati rendszerekben alkalmaz- 
ható. A windowsos munkaállomásokat tartalmazó 
hálózatokban ugyanakkor nemcsak elfogadható, 
de kifejezetten előnyös, márpedig tudomásunk 
szerint Oroszországban ezek a rendszerek terjedtek 
el leginkább. A fő előny itt az, hogy lehetőség 
nyílik a proxyhitelesítés összevonására a windowsos 
és a Samba alapú tartományvezérlőkre szóló hite- 
lesítéssel. 


A körülmények elemzésével és néhány ötlet nyomán 
kétféle rendszert dolgoztunk ki: 


1. VPN, PPTP használatával, a tűzfal beépített 
szolgáltatásaira építve. A VPN-kiszolgáló hagyo- 
mányosan FreeBSD volt, ezért az ipfw tűzfalfelületet 
és az mpd PPTP-kiszolgálót alkalmaztuk. A forga- 
lomszabályozást az ingyenesen elérhető NetAMS 
rendszer végezte. 
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2. Sguid-alapú hozzáférés-vezérlési és felügyeleti 
rendszer. 


Az első rendszert Vladimir Kozlov fejlesztette ki, feladata 
az egyetem az internet elérésére állandó gépet használó 
munkatársai által használt kapcsolatok biztosítása. Legna- 
gyobb hátránya az, hogy ügyféloldali VPN-telepítést igé- 
nyel. Ez elég komoly gondot jelent, ha a hálózat elemei 
szétszórtan helyezkednek el, és a felhasználók kevésbé 
jártasak a számítógép használatában. 

A második megoldás Tagir Bakirovhoz kötődik, segítségével 
történik az egyetemi felhasználók túlnyomó részének csat- 
lakoztatása — ők azok, akik nem rendelkeznek állandó gép- 
pel. Ennek kapcsán a fő problémát a fejlesztés bonyolultsá- 
ga jelentette; a továbbiakban ennek részleteit tárgyaljuk. 


Sguid-alapú internetes hozzáférés-vezérlési 

és felügyeleti rendszer 

Mindenek előtt szeretnénk felhívni rá a figyelmet, 

hogy az itt szereplő elérési utak mindig a Sguid forrásának 
alapkönyvtárához viszonyítva értendők, ami a mi ese- 
tünkben a /usr/local/src/sguid-2.5STABLE7/ volt. A Sguid 
beszerzésével, lefordításával és használatával kapcsolato- 
san a Sguid webhelyén lehet részletes útmutatást találni. 
Fussuk át a Sguid néhány jellemzőjét, ezek a Sguid 
Programming Guide-ból származnak. 

A Sguid egy egyfolyamatos proxykiszolgáló. Minden ügyfél 
HTTP-kéréseit a főfolyamat kezeli. Futása lényegében 
visszahívó függvények sorozata. A visszahívó függvény 
végrehajtására akkor kerül sor, amikor a be/kivitel elvégez- 
hető vagy valamilyen más esemény történt. Amikor 

a visszahívó függvény végzett, bejegyzi a következő be/ki- 
viteli művelet visszahívó függvényét. 

A Sguid alapját a select(2) és a poll(2) rendszerhívás 
adja, melyek be/kiviteli eseményekre várakoznak fájl- 
leírók egy csoportján. A Sguid ezekkel végzi el a meg- 
nyitott fájlleírók be/kiviteli műveleteit. A selectO 
rendszerhívást a comm select) függvény adja ki, 

mely a teljes fd table[] tömböt letapogatja, kezelő- 
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függvényeket keresve. Az eljárás minden kész leíró- 

hoz meghívja a megfelelő kezelőt. A kezelőfüggvé- 

nyek bejegyzése a commsetSelect O, a lezáró kezelők 
meghívása pedig a comm closeO) függvénnyel történik. 
A lezáró kezelők feladata a fájlleírókhoz rendelt adat- 
szerkezetek felszabadítása. Ez az oka annak, hogy min- 
den hívássorozatot a comm close() meghívásának 

kell zárnia. 

Érdekes Sguid-szolgáltatás az ügyfél/IP-cím adatbázis támo- 
gatása. Kódja a src/client db.c fájlban található. Alapeleme 
egy kivonat alapján indexelt tábla (client. table), mely 
clientInfo adatszerkezetekre vezető mutatókat tartalmaz. 
Ezek az adatszerkezetek különböző adatokat tartalmaznak 
a HTTP-ügyfélről és az ICCP proxykapcsolatokról (mint 
például kérés-, forgalom- és időszámlálók). A src/structs.h 
fájl vonatkozó kódrészlete: 


struct .  Clientinfo ( 
/: elsőnek kell lennie 7/ 
hash link hash; 
struct in addr addr; 
struct ( 
int result hist[LOG TYPE MAXI ; 
int n reguests; 
kb t kbytes in; 
kb t kbytes out; 
kb t hit kbytes out; 
l Http, Icp; 
struct ( 
time t time; 
int n reg; 
int n denied; 
l cutoff; 
/" a jelenleg létrejött kapcsolatok 
sszáma "/ 
int n established; 
time t last seen; 


1 


Néhány fontos átfogó és helyi függvény az ügyféltábla 
kezeléséhez: 


e  clientdbínit() - Átfogó, az ügyféltábla kezdeti érték- 
adását végző függvény. 


e  clientdbupdateO - Átfogó függvény, szükség 
szerint a táblában lévő rekordot frissíti vagy új 
rekordot hoz létre. 


e  clientdbFreeMemory() - Átfogó függvény, 
törli a táblát és felszabadítja a hozzárendelt 
memóriát. 


e clientdbaddO - Helyi függvény, a clientdbupdateO) 
hívja meg; hozzáadja a rekordot a táblához, illetve üte- 
mezi a szemétrekordokat összegyűjtő eljárást. 


e  clientdbFreeltemO -— Helyi függvény, 


a clientdbFreeMemoryO függvény hívja meg, 
és egyetlen rekordot távolít el a táblából. 
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e clientdbsheduledGCc(), clientdboccO 
és clientdbstartGCcO) — Helyi, a szemétrekordokat 
összegyűjtő eljárást megvalósító függvények. 


Párhuzamba állítva a rendszerrel szemben támasztott 
követelményeket és a meglévő ügyféladatbázis által 
nyújtott lehetőségeket, kijelenthetjük, hogy az alap- 
szolgáltatások egy része máris megvalósult, kivéve 

az ügyfelek felhasználóneve szerinti indexelést. 

A meglévő ügyfélstatisztika-adatbázis további sú- 
lyos hiányossága, hogy az adatok frissítése csak azt 
követően történik meg, hogy az ügyfél a teljes kért 
tartalmat megkapta. 

Munkánk során egy másik párhuzamos és független, 
ügyfél/felhasználó adatbázist készítettünk, kisebb mó- 
dosításokkal a src/client db.c fájlban található kódot 
felhasználva. A felhasználói statisztikák a clientiInfo. sb 
adatszerkezetbe kerülnek. Az src/structs.h fájl vonat- 
kozó része: 


$ifdef SB INCLUDE 
$fdefine SB CLIENT NAME MAX LENGTH 16 
struct . Clientinfo sb f 
/" elsőnek kell lennie "/ 
hash link hash; 
char "name; 
unsigned int GID; 
struct ( 
long value; 
char type; 
long cur; 
time t lu; 
l Imt; 
/" HTTP-kérések számlálója "/ 
int Counter; 
b; 
fendif 


Az ügyféladatbázis kezelését a következő — az előbbi- 
ekhez roppant hasonló - átfogó és helyi függvények 
végzik: 


e  clientdbinit sbO — Átfogó, az ügyféltábla kezdeti 
értékadását végző függvény. 


e  clientdbupdate. sb() - Átfogó függvény, mely 
frissíti a táblában lévő rekordot, a korlát elérésekor 
leválasztja az ügyfelet, illetve szükség esetén 
a clientdbadd sbO meghívásával hozzáadja 
az új ügyfelet. 


e clientdbestablished sbC) - Átfogó függvény, 
mely megszámlálja az ügyfélkéréseket, és rendszeres 
időközönként beírja a megfelelő rekordot a fájlba, 

a korlát elérésekor leválasztja az ügyfelet, illetve 
szükség esetén a clientdbadd sbO függvény meg- 
hívásával hozzáadja az új rekordot. 


e  clientdbFreeMemory. sb() - Átfogó függvény, törli 
a táblát és felszabadítja a hozzárendelt memóriát. 


1. kódrészlet A clientWriteCompletef) és a clientReadReguest() 
függvény egyes részei az src/client side.c fájlból 


static void 
clientwritecompleteCint fd, 
char "bufnotused, 
size t size, 
int ernkiag; 
void "data) 


clientHttpReguest "http - data; 


"A EGúsüzesst0) 
ji 


kb incr(gstatCounter.client http.kbytes out, 
size); 
/"-Itt kezdődik az SB rész--------—-- tt 87 
$ifdef SB INCLUDE 
if (http-sreguest-sauth user. reguest) 
úÚ 
if ( authenticateuserReguestusername( 
http-sreguest- 
sauth user reguest) ) 
if (!clientdbupdate sb( 
authenticateuserReguestusername( 
http-sreguest-sauth user reguest), 


size) ) 
í 
comm close(fd); 
return; 
ik 
3 
ftendif 
/ JE GE Ez sá ET Eez EE esze el a E e EGES S E Ea SET el JEE szszei ESZ S ESNE E El ed ÉL SS ES ES E zsak SE TE 5 
if CisTcpHit(http-:1og type)) 
kb incr( 
€statCounter.client http.hit kbytes out, 
size); 
3 


static void 
clientReadRgeguest(int fd, void "data) 
ú 
CconnStateData "conn -— data; 
int parser. return code — 0; 
reguest t "reguest -— NULL; 
int size; 
void "p; 
method t method; 
clientHttpReguest "http -— NULL; 
clientHttpReguest ""H - NULL; 
eharréspire lies alNY TELE 
ErrorState "err - NULL; 
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fde "F - efd tablelfd]; 
int len - conn-sin.size - conn-sin.offset - 1; 


/" A kérés törzsének feldolgozása, ha van 

szjjillyen 87 

if (conn-sin.offset 5 0 8 
conn-sbody.callback !- NULL) 


clientProcessBody (conn) ; 
ű 
/" A következő kérés feldolgozása "/ 
while (conn-sin.offset 5 0 é£ 
conn-sbody.size left -—— 0) 


int nreguests; 
size t reg line sz; 


/" Kérés feldolgozása "/ 
http - parseHttpReguest(conn, 
gmethod, 
gparser return. code, 
eprefix, 
£$reg line sz); 
TE SGINEtDI 
safe free(prefix); 
TC EDDEK 


if (reguest-smethod -—— 
55 METHOD. CONNECT) 


jú 
/" Kérések beolvasásának 
S leállítása... "/ 
commsetSelect(fd, 
COMM SELECT. READ, 
NULL, 
NULL, 
095 
clientaAccesscheck (http) ; 
/:-Itt kezdődik az SB rész----------—-—--—-——— 4/ 


$ifdef SB INCLUDE 

if(http-sreguest 

5 -sauth user reguest) 

í 

a 
authenticateuserReguestUusername( 
http-:sreguest-sauth user. reguest 

DJ TENYISU 


if(!clientdbcount sb( 
authenticateUuserReguestusername( 
http-sreguest 
5 -sauth user. reguest))) 
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o 
£ 1. kódrészlet (folytatás) 
A 
— 
z 
2 
o) í authenticateuserReguestusername( 
sa comm close(fd); http-sreguest 
§ return; 5 -sauth user reguest))) 
a J ( 
s b comm. close(fd) ; 
j J return; 
éz tendif ij 
2 /8--——reer erre ree errre errre 1/ J 
g break; ) 
5 l else ( ftendif 
Sz clientaáAccessCcheck (http); [/7--—-———————————————————————————————————————— 136770 
o /"-Itt kezdődik az SB rész-----—----————————— Y/ — /7 while offset 5 0 €£g body.size left 
ftifdef SB INCLUDE 5-- 0 "/ 
if(http-sreguest continue; 
5 -sauth user. reguest) 3 
sú )l else if (parser. return code —— 0) ( 
nana Se 
authenticateUuserReguestusername( /" while offset 5 0 €8 conn-sbody.size left 
http-:reguest-sauth user. reguest s NÜ 7 
)!-NULL) h 
í ; 
ifC(!clientdbcount. sb( d 
e clientdbaádd sbO - Helyi függvény, e AcdlientdbEstablished sbO függvény meghívása 
a clientdbupdate sbO hívja meg; hozzáadja az ügyfél kérését feldolgozó cl ientReadReguestO 
a rekordot a táblához, illetve ütemezi a szemét- függvényből. 


rekordokat összegyűjtő eljárást. 
Az 1. kódrészlet az src/client side.c fájlból 


e clientdbFlushItem sbO - Helyi függvény, a clientwritecompleteO és a clientReadRgeguestŐ 
a clientdbEeEstablished sbO és függvény megfelelő részeit tartalmazza. 
a clientdbFreeItem sbO hívja meg; A kód működése rendkívül egyszerű. A 2. ábra az ügyfelek- 
a megadott rekordot írja ki a fájlba. től érkező kérések feldolgozásának folyamatát szemlélteti 
a rendszer szemszögéből. Minden az ügyfelektől érkező ké- 
e clientdbFreeItem sbO - Helyi függvény, rés tartalmazza a hitelesítési adatokat, köztük a felhasználó- 
a clientdbFreeMemory sbO függvény hívja meg, nevetis. A clientdbupdate sbO függvény megkeresi a ké- 
és egyetlen rekordot távolít el a táblából. résben szereplő felhasználónévhez tartozó Clientinfo. sb 
rekordot. Ha nincs ilyen rekord, akkor a hitelesítési fájlok 
e clientdbsheduledGc sbO, clientdbec sbO tartalma alapján új clientInfo. sb rekordot hoz létre. Ha 
és clientdbSstartGc sbO) - Helyi függvények, a felhasználók túllépik korlátjukat, akkor a comm closeO 


a szemétrekordokat összegyűjtő eljárást valósítják meg. függvény azonnal megszakítja a kapcsolatukat. 
A clientdbestablished sbO függvény meghívása az ügy- 
Az ügyféladatbázis kezdeti értékadásának és elengedésének  félkérések számának szabályozását szolgálja, illetve az aktu- 


megvalósítása az eredeti táblához hasonlóan az src/main.c ális felhasználói információk elmentését a hitelesítési fájlok- 
fájlban található. Kódunk legfontosabb jellegzetessége ba, minden SB MAX COUNT kérés után. A hitelesítési fájlok 
a clientdbupdate sbO és a clientdbEstablished sbO neve — a unixos világban megszokott módon - passwd és 
függvény meghívása a src/client side.c fájl ügyféloldali eljás: — group. A passwd fájl tartalmazza a felhasználói, a group 
rásaiban: pedig a csoportokkal kapcsolatos adatokat. Például: 
e Aclientdbupdate sbO függvény "passwd" : 
meghívása a külső clientwritecompleteO) fcnév3:cteljes név: :ccsoportazonosítós : 
függvényből, mely az adatok ügyfél felé fcjelenlegi korláts:ckorlát utolsó frissítésének 
történő elküldéséért felelős. 5 időpontjaz 
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4 Proxy kiszolgáló 









































Böngésző 
1 
select() 
GET index.htm 
elientReadReguest() ( 
elientAccessCheck () ; 
€ HTTP 407 ! 
Proxy Authorization Reguired 
select() 
GET index.html ] 
(user: foo, password: "eese) elientReadReguest() ( 


elientAccessCheck() ; 
if(lelientdbCount sb()) 
comm close(); 

















! 








elientSendMoreData() ( 


if(!elientdbupdate sb()) 
comm close(); 














HTTP 200 OK: ; 


elientSendMoreData() ( 





if(lelientdbupdate sb()) 


OR 
I comm c1ose (); 
) 
Í 28 ] 
ol 
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eclientReadReguest() ( 
elientAccessCheck 0; 


if(!clientdbCount sb()) 


comm close(); 
28 I 
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li) The page cannot be displayed 

















2. ábra Ügyféltől beérkezett kérés feldolgozásának folyamata 


tagir:Tagir Bakirov:1:6567561:12346237467 
"group" : 

fcnév::cteljes név: :ccsoportazonosítós : 
fccsoport korlátjaz:ccsoportkorlát típusaz 
users:BSPU users:1:10000000:D 


Háromféle korlát létezik: D (daily, napi), w (weekly, heti) 
és M (monthly, havi). A passwd és a group fájl nevét 

lehet megadni, ez a sguid.conf sablonfájl és a Sguid 
beállításait tartalmazó adatszerkezet módosításával 

vált lehetővé. 

Néhány további apróbb, a Sguid forráskódján végrehajtott 
módosítás: 


e Átfogó függvények meghatározása az src/protos.h 
fájlban 


e Aclientinfo. sb adatszerkezet típrusmeghatározása 
az src/typedefs.h fájlban 


e Aclientinfo. sb adatszerkezet azonosítójának meg- 
adása az src/enums.h fájl adatszerkezet-listájában 


e ACclientinfo. sb adatszerkezet kezdeti értékadása 
a meminit OO memóriafoglaló eljárásban, az src/mem.c 
fájlban 


Minden módosítást hasonlóan végeztünk el a kódban is, 


megőrizve az eredeti ügyfél/IP-cím adatbázist. Reméljük, 
semmit nem rontottunk el. 
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Áttekintve a módosításainkat, bizonyára feltűnt, hogy 
minden kódunkat feltételes fordítást előíró itifdef 

SB INCLUDE ... itendif szakaszokba helyeztük. 

Az SB. INCLUDE változó akkor kerül megadásra, ha 

az --enable-sbclientdb átadott érték szerepel a Sguid 
beállító parancsfájljának parancssorában. Ehhez az 
autoconf segítségével újra kellett fordítanunk 

a configure.in parancsfájlt — előtte elvégeztünk rajta 
néhány apróbb változtatást. 


Osszefoglalás 

Írásunkban áttekintettük az internetelérés szabályozá- 
sának problémáját. Több megoldást is javasoltunk rá, 
majd részletesebben is ismertettük a Sguid proxy- 
kiszolgálóra épülőt, amelyet egyetemünk helyi hálóza- 
tában is megvalósítottunk. Tisztában vagyunk vele, 

hogy megoldásunk nem hozza el a megváltást, valamint 
nyilván számos hátránya is van, ám egyszerű, rugalmas 
és teljesen nyílt. 

Webes programozónk, Elmir Mirdiev mostanában fejez be 
egy kisebb, PHP alapú webhelyet, amelyen keresztül mód 
nyílik majd a rendszer felügyeletére és a felhasználói sta- 
tisztikák lekérdezésére. Utóbbiakat a Sguid naplóiból a Sarg 
rendszerrel állítjuk elő. 

További tudnivalók a rendszer forráskódjában találhatók. 
Webhelyünkről a Sguid 2.5STABLE7 kiadásának teljes mó- 
dosított változata és a megfelelő foltok külön is letölthetők. 
Bárki kérdéseit örömmel fogadjuk elektronikus levélben. 


Linux Journal 2005. június, 134. szám 





Tagir K. Bakirov (batkamail.ru) rendszergazda 

a BSPU-nál és első éves doktoranduszhallgató az 
Ufai Állami Repüléstechnikai Egyetemen. Főként 
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2 www.bspu.ru 

2 www.netams.com 

2 www.sguid-cache.org 

2 www.sguid-cache.org/Doc/FAO/FAO-2.html 

2 www.sguid-cache.org/Doc/Prog-Guide/ 
prog-guide.html 

5 sarg.sourceforge.net 

2 www.bspu.ru/sguid/sguid-2.5STABLE7. sb. tar.gz 

2 www.bspu.ru/sguid/sguid-2.5STABLE7.sb.patch 
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Gentoo másképp 


A Gentoo-t legtöbben a fejlesztői munkaállomások egyik vezető terjesztésnek 
tekintik, de az egyszerű csomagkezelési rendszer miatt olykor jó választás lehet 
bármely folyamatosan naprakész termelési rendszerben. 


e kell vallanom valamit. Gentoo Linuxot használok. 
B Kollégáim a különféle Linux felhasználói csopor- 

tok találkozóin úgy gondolják lökött vagyok. Min- 
denki tudja, hogy a Gentoo forráskód alapú Linux- 
terjesztés. A Gentoo általános elképzelés szerint (amit igen 
nagy mértékben befolyásoltak a terjesztést fejlesztő embe- 
rek) olyanoknak való, akik extrém mértékű optimalizálást 
szeretnének, és igazából csak azoknak felel meg, akik asztali 
gépen használják. Valójában a Gentoo meglepő módon ren- 
geteg más feladatra is ideális. Nem kis meglepetésemre né- 
hányan már manapság is Gentoo-t használnak termelési 
környezetben pontosan ezek miatt az okok miatt. 


Sebesség 

Minthogy az eredeti i386 processzor leszármazottai binári- 
san együttműködőek, más Linux terjesztések (nem beszélve 
azokról akik Microsoft Windowshoz írnak programokat) 
programjuk előrecsomagolt bináris változatát a gyakori 1386 
rendszerre készítik el kihasználva, hogy így az mindenhol 
fut. A dolog másik oldala, hogy ezek a terjesztések nem 
tudják kihasználni azokat az új képességeket amelyeket 
okos processzorunk nyújthatna, ami azért kár. 

A Gentoo ezzel szemben forrásból-épített terjesztés ahol 
beállíthatjuk a fordítókapcsolókat amikor rendszerünkhöz 
alkalmazásokat telepítünk. A GCC ugyanis lehetővé teszi, 
hogy meghatározzuk a CPU típusát, amelyen a kódot futtat- 
ni szándékozzuk. A processzortípus meghatározásával 
(például Intel Pentium III vagy AMD Athlon Thunderbird) 

a fordító képes processzorfüggő kódot készíteni, amely (leg- 
alábbis elméletben) jobb, gyorsabb gépi kódot eredményez. 
Gyorsabb tehát a Gentoo rendszer? Anekdotákon alapuló 
bizonyítékok elég változóak. Úgy tűnik a Gentoo rendszerek 
valamivel gyorsabban futnak mint egy azonosan beállított 
népszerűbb terjesztés rendszere. Azonban bármilyen apróbb 
teljesítmény előny azonnal értelmét veszti, ha a rendszer 
nincs helyesen telepítve beállítva és finomhangolva. Mint- 
hogy a legtöbben nem tudjuk hogyan kell ezt csinálni és 
mivel a Gentoo olyan nagy mozgásteret nyújt a saját megol- 
dásainknak, ha valami butaságot csinálunk, könnyen elve- 
szíthetjük a némiképp gyorsabb programok előnyét. 

Így sebesség tekintetében voltaképp nem igazán számít, 
hogy forrásból-felépített vagy bináris alapú terjesztést 
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használunk-e. De ha a nagyobb sebesség nem érv a Gentoo 
mellett, akkor meg mi értelme van egyáltalán ennek 
a forrásból telepítés dolognak? 


A termelési környezetek általános problémái 

Az embereket több módon is felbosszanthatja számítógépük. 
Amire mi most koncentrálni próbálunk egy újabb keletű 
probléma, amelybe az új operációs rendszerek két esetben 
futnak bele. Az első eset, amikor a felhasználó valami olyan 
eszközkészletet szeretne, ami a terjesztésben nem talál meg. 
Eredményképpen a felhasználónak magának kell összeállí- 
tania azt. A második eset amikor a terjesztésben rendelke- 
zésre álló csomagnak új verziója jelenik meg. Mindkét eset 
a kulcsa: az egyszerű megoldhatóság. Kérdés, hogy mennyi- 
re segít bennünket az operációs rendszer a karbantartást kí- 
sérő buktatók során? Legnagyobb meglepetésemre, a Gentoo 
Linux úgy tűnik igazán jónak bizonyult ebben a tekintetben. 
A Gentooval új csomagokat úgy telepítünk, hogy letöltjük 

a forrást és befordítjuk. Egy programot szeretnénk? Semmi 
gond, kiadunk egy utasítást és kicsivel később már fenn is 
van. Olyan mintha Debiant használnánk. 

Gentoo akkor csillogtatja meg igazán tudását, amikor 

a felhasználónak újabb verziójú programra van szüksége. 
Tegyük fel a Bluefish HTML szerkesztőt használom, ám egy 
hiba idegesít benne. Könnyen lehet, hogy a Bluefish újabb 
verziója már megtalálható a Gentoo Portage nevű csomag- 
kezelő rendszerében, így lehet, hogy máris lekérhetem 

a frissítést. A Gentoo hasznos etcat parancsa megmutatja 
nekünk mit érhetünk el: 


ff etcat versions bluefish 


Az etcat azt mondja, hogy a 0.9-es bluefish van telepítve 
viszont már elérhető a 0.12-es is. A bluefish weblapjáról 
megtudom, hogy a 0.12-esben már javították a hibát, tehát 
biztosan frissíteni szeretnék. 

A emerge parancs megmutatja mi fog történni ha frissítek: 


f emerge --pretend bluefish 


Úgy tűnik ennek a biuefish verziónak szüksége van 
a libpcre nevű könyvtárra. A Portage azt mutatja nekünk, 








app-editors/bluefish 
j Ji 





1. ábra Az etcat eszközzel lekérdezhetjük milyen bluefish verzió áll 
rendelkezésünkre 





2. ábra Az emerge — pretend segítségével ellenőrizhetjük a telepítendő 
program függőségeit 


hogy a bluefish frissítésén felül a libpcre könyvtárat is le 
fogja tölteni. Lássunk neki: 


$ emerge bluefish 


A Portage először letölti, lefordítja és telepíti a libpcre-t, vé- 
gül ugyanezt végrehajtja a bluefish esetében is. Négy perc- 
cel később kész is a frissítésem. Hát ez nem volt túl nehéz. 
Biztosan észrevették, hogy nem a 0.13-as verziót ajánlott fel 
telepítésre. Ez azért van, mert jelenleg a 0.13-as verzió 
maszkolt, ezért volt vörössel jelölve. Ebben a felállásban a 0.13 
éppen csak kijött, de már van hozzá ebui ld. Ez az ebuild 
azonban még tesztelés alatt áll, hogy kiderüljön, a program 
ténylegesen telepítődik-e és nincs-e véletlenül valami durva 
hiba benne. Amennyiben tényleg szükségünk lenne rá, felül- 
bírálva a Portage döntését utasíthattuk volna, hogy a 0.13-ast 
hozza le. Ugyanígy, ha okom van rá, választhattam volna 

a 0.11-est is. Ez a rugalmasság a Gentoo legnagyobb ereje. 


Csináld magad csomagok 

Egy kicsit trükkösebb eset amikor olyan programot szeret- 
nénk felrakni amit nem támogat a rendszer. Az egyik leg- 
fontosabb ok amiért terjesztésekben bevezették a csomag- 
kezelést, hogy egyetlen egységes rendszerben láthassák, 
milyen programok vannak a rendszerre telepítve. Minden 
egyes programhoz, legyen az alapprogram, rendszerkönyv- 
tár, kiszolgáló program vagy felhasználói alkalmazás, egy 
csomagot készítenek. Ahogy a csomagot a rendszerre tele- 
pítjük, az operációs rendszer rögzíti, hogy mely állományok 
hova kerülnek, majd a csomag a rendszerre kerül. Ezzel 

a módszerrel a csomagtól függő más csomagok már tudni 
fogják, hogy az előkövetelményeik a helyén vannak. 

De mi történik, ha újabb verziót akarunk feltenni egy prog- 
ramból, amihez nem készült megfelelő csomag az operációs 
rendszerünkhöz? Általában ugyanazt az utat kell bejárnunk 
mint a csomag eredeti készítőjének, kivéve ha a következő 
két dolog valamelyikét választjuk: 


1. Egyedi helyre telepítjük, valószínűleg a /usr/local/bin 
könyvtárba, majd biztosítjuk, hogy a régi helyett az új 


program fusson. 


2. Vakon telepítjük a programot a gyökér fájlrendszer- 
re, reménykedve hogy nem nyiffantunk ki valamit 
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közben, és imádkozunk, hogy a később telepítendő 
dolgok nem fognak semmit felülírni a most feltett 
dolgok közül. 


Gondolkozzunk csak el ezen egy kicsit. Nem találjuk furá- 
nak ha valaki nem aggódik ilyesmi miatt? Végül is nem ép- 
pen ez az, amit a csomagkezelésnek meg kellene előznie? 
Nem az a kérdés, hogy , lehet-e csomagokat készíteni", mert 
erre a válasz ,igen, teljeskörűen", és nem is az, hogy , létre 
tudjuk-e hozni saját csomagjainkat". Sokkal inkább azt sze- 
retném tudni, hogy milyen nehéz mindezt végrehajtani. 
Tegyük fel, hogy fenn van az OS-ból feltett bogofilter 
programunk és a 0.16.1-es verzióhoz való rpm csomagunk. 
Hirtelen a bogofilter alkotója rádöbben, hogy egy buta, 
ám igen súlyos hiba rejtőzik a változatban, ezért gyorsan 
kiad egy 0.16.2-os frissítést. 

A probléma ott kezdődik, hogy kénytelenek vagyunk meg- 
várni amíg a terjesztésünk kiadja a saját rpm, .deb, pkg 
vagy más egyéb változatát, ami akár sokáig is eltarthat, így 
rákényszerülünk, hogy saját változatot készítsünk. Nos, ek- 
kor jönnek a problémák. Elméletileg az .rpm vagy .deb cso- 
magok létrehozása egyszerű. , Alapnak egyszerűen csak ve- 
gyük a már meglévő 0.16.1 csomagot". Csakhogy a legtöbb 
embernek, legalábbis akik nem állnak mágus szinten (de 
néha még nekik is) elég komoly kihívást jelent az ilyesmi. 
Saját magunknak kell: 


e — Letölteni a csomag leírást vagy valahogy kiszednünk 
egy meglévő csomagból. 


e Kézzel letöltenünk és kicsomagolnunk a legújabb .tar.gz 
(vagy éppen ami) forrást. 


s  Átkell alakítanunk a leírásokat (a Debian esetében a leg- 
frissebb forrásokba) sőt előfordulhat, hogy meg is kell 
foltoznunk azokat. 


e Lehet, hogy meg kell változtatnunk az behúzó-parancs- 
fájlt, hogy helyesen működjön az új verzió esetében is. 


e Ezután megpróbálhatjuk létrehozni a csomagot. 
Ehhez először is le kell fordítanunk, ami valószínűleg 
jó néhány -dev csomag feltelepítését jelenti amelyekről 
azelőtt azt sem tudtuk, hogy léteznek. 


e — Végül telepítünk és tesztelünk. 


Mindez természetesen kivitelezhető ugyan, de a szükséges 
ismeretek megszerzése igencsak meredek tanulási görbét 
jelent (különösen az újaknak). Akárhogy is nézzük, ez elég 
sok munka amit szívesen kihagynánk. 


A Gentoo csomayleírásai 

Bár alapvetően nem különbözik a fent leírt folyamattól, 
csomagokat telepíteni egy Gentoo rendszerre könnyebb. 

A trükk a Gentoo egyszerű formátumú ebui1d csomag- 
leírásaiban rejlik. Ezek lényegében héjprogramok (az 
ebuilds-al később még foglalkozunk a cikkben). A folyamat 
közben megadjuk honnan kell beszerezni a forrás tarlab- 
dát. Amikor fordítunk, a Portage letölti a forrást majd 
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elkezdi kitömöríteni és lefordítani. Mivel héjprogramok- 
ról beszélünk, nagy hatékonysággal tudják használni 

a héjváltozókat. A verziószámot az ebuild fájlnév értel- 
mezésével nyeri ki majd egy olyan változóba teszi, amit 
a parancsfájl fel tud használni. 

A fenti bogofilter példánkban, a csomagállomány (mely- 
nek neve bogofilter-0.16.1.ebuild) a következő sort tartal- 
mazza: 


SRC URI-"http://sourceforge.net/downloads/ 
sbogofilter-$íPv3.tar.gz" 


Amikor belefogunk a bogofiltert felkészítésebe és fordí- 
tásába, a Portage a fájlnév alapján a $Pv változót 0.16.1-re 
állítja és a megfelelő .tar.gz állományt tölti le. Ezek után 
kicsomagolja, majd a 


. /configure 
make 
make install 


parancsok futtatása után az utasításoknak megfelelően 
felépíti a csomagot. Amennyiben létre szeretnénk hozni 

a kívánt 0.16.2-es új verziónkhoz tartozó ebuild állományt 
a következőket kell tennünk: 


ff cd /usr/portage/net-mail/ 

tf cp bogofilter-0.16.1.ebuild 

5 bogofilter-0.16.2.ebuild 

tt ebuild bogofilter-0.16.2.ebuild digest 


Feltételezve, hogy a csomagleírásban és a kicsomagolási 
útmutatókban semmi frissítendő nincsen, mindössze ennyit 
kell tennünk. 

Van még pár dolog amire érdemes odafigyelni. Például, 

a fentieket valószínűleg inkább a /usr/portage fa külön 
másolatán szeretnénk végrehajtani, hogy ne veszítsük el 
változtatásainkat ha az elsődleges fa esetleg megváltozik. 
A Portage közvetlenül is támogatja ezt. Ha kíváncsiak va- 
gyunk, hogyan kell megmutatni a Portage-nek hol tároljuk 
a saját ebuild-jeinket, nézzük meg a PORTAGE. OVERLAY vál- 
tozó leírását a hálózati dokumentációban vagy közvetlenül 
a /etc/make.conf állományban. Most már kiadhatjuk 

a Portage-nek a 


ft emerge bogofilter 


parancsot és máris megvan az új verziónk. 

A Gentoo valamennyi csomagjának forrás tarlabdájából má- 
solatokat tart fenn a világszerte megtalálható tükrein. Nor- 
mál esetben a Portage az egyik ilyen gépről tölti le a forrást. 
Akkor sincs semmi probléma, ha esetleg valami olyasmit 
fordítanánk ami nincs fenn a Gentoo tükrein. A Portage egy- 
szerűen az eredeti, fejlesztői letöltőoldalt fogja használni. 

A Portage mdSsum összegekkel ellenőrzi a letöltött állomá- 
nyok hibátlanságát. A fenti harmadik parancs (ebuild . . . 
digest) éppen ezért került oda. Miután letöltöttük a forrást 
így az md5sum ellenőrzést is rögtön elvégezzük. Mivel 
most mi hajtjuk végre a verzióugrást, nekünk kell ellenőriz- 
ni, hogy biztosan hibátlan-e a letöltésünk. Ezért aztán érde- 
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mes először az ebuild . . . unpack paranccsal megszerezni 
a letöltést, meggyőződni a hibátlanságáról, és csak ez után 
feldolgozni a parancsot. 

Végül, ha olyan programcsomagot szeretnénk, amit az 
operációs rendszerünk nem támogat, meg kell írnunk 

a sajátunkat. A Gentooval nagyon könnyen készíthetünk 
saját ebuild-et. 


Minden, amit az ebuildről tudni kell 

A Gentoo csomagleírásai Bash-ben készültek. A különféle 
utasítások függvényekbe kerülnek amelyeket a Portage 
hív meg a folyamat során. A főbb elemek: 


pkg. setupO 
src unpackO 
src compileO) 
src installO 
pkg preinstO 
pkg postinstO 


Ezek sorrendben hívódnak meg. Ha meg akarjuk mu- 
tatni a Portagenek, hogyan készítse el a programunkat, 
írjuk meg a lépésekhez tartozó függvényeket, mindegyiket 
ellátva némi információval, mint például a korábban emlí- 
tett SRC URI. 

A forrásaink fordításához például a következőket 
használhatjuk: 


src compile O ( 
./configure --prefix-/usr 
make 


Hi 


Ezekben a héjprogramokban az a csodálatos, hogy felülde- 
finiálható, alapértelmezett változattal rendelkeznek. 

Az alapértelmezett src compileO) valójában igen hasonló 
az itt bemutatotthoz, ami sok csomaghoz tökéletes. Tulaj- 
donképpen akár olyan ebuild-et is készíthetünk, amely 
teljes egészében az alapértelmezett változatokat használja 
és egyáltalán nem rendelkezik saját függvényekkel. 

Néha előfordul, hogy egy csomagot rendszertől függően 
másképpen szeretnénk beállítani a . /configure-al. A Portage 
letc/make.conf-ban található és parancssorból felülbírálható 
USE környezeti változója olyan tokeneket tartalmaz, amelyek 
a rendszerünk testreszabásában és leírásában segíthetnek. Te- 
gyük fel, hogy van egy csomagunk, amit többféleképpen is le 
lehet fordítani attól függően, hogy szeretnénk-e mondjuk X 
Window System vagy IPv6 támogatást. Az src compileO 
függvényünk a következőképpen nézne ki: 


src compile O ( 
use X ég conf-"$íconf3 --with-x" 
use ipv6 I] conf-"$íconft --without-ipv6" 
./configure --prefix-/usr $íconf3 
make 


; 


Különféle héjprogramozási megoldásokkal találkozhatunk 
itt. A fenti példánkban ha a rendszerünkön van X, a cso- 
magnak megüzenjük, hogy készítsen X támogatást. 


1. lista ssh2-3.2.9.1.ebuild 


DESCRIPTION-"ssh.com"s implementation of SSH2" 
SRE URTI—" 
ftp://mirror . aarnet . edu . au/pub/ssh/ 
5 ssh-$íPv3.tar.gz 
ftp://ftp. ssh. com/pub/ssh/ssh-$íPv3. tar.gz" 
HOMEPAGE—" http: //ww. ssh. com/products" 
SOT SÜN 
LICENCE-"free-noncomm" 
KEYWORDS-"7x86 -ppc" 
RDEPEND-"virtual/glibc 
!net-misc/openssh 
szsys-libs/zlib-1.1.47 
DEPEND-—" $(RDEPEND3 
dev-lang/per1 
:-sys-apps/sed-4" 
PROVIDE-"virtual/ssh" 
IUSE-"X ipv6" 
RESTRICT-"nomirror" 
t A csomagot ssh2-nek hívjuk; a forrás 
t tarlabdák alakja ssh-x.y.z Ezért felül kell 
t írnunk az S-t, hogy kicsomagoláskor a helyes 
t könyvtárra mutasson. 
S-"$(WORKDIR3/ssh-$íPv3" 
ft Itt valószínűleg hagyatkozhattunk volna az 
s alapértelmezésre is 
src unpackO ( 
unpack $(Al 
8 
ft A nagyszámú configure kapcsoló közül 
ft az X windows és az Ipv6 befordításának 
ft lehetőségét kezeljük le itt. 


src compileO ( 
local conf 
use X €8. conf-"$í(conf3 --with-x" 
use ipv6 I] conf-"$ífconfz --without-ipv6" 
./configure $íconfl --host-"$(CHOSTFEN 
--prefix-"/usröN 
--with-ssh-agent1-compat N 
--with-etcdir-"/etc/ssh27N 
II die "configuration failed" 
make I] die "compile failed" 
3 
ff ez is szinte azonos az alapértelmezettel, 
ft de az rc parancsfájl nevét meg szeretnénk 
sváltoztatni 
src.installO ( 
make DESTDIR-$íD3 install 
exeinto /etc/init.d 
newexe $íFILESDIRj/sshd2.rc sshd2 


Amennyiben kiszolgálóról van szó és erre semmi szüksé- 
günk, a programunk a felesleges részek nélkül készül el. 
Az USE változókat a parancssorból felülbírálhatjuk, így 


ha szükséges még pontosabb vezérléssel is dolgozhatunk. 


www.linuxvilag.hu 


Az src unpackO ugyanígy működik. Amennyiben 

nem adunk meg semmit, a Portage nekilendül, az alap- 
értelmezett helyre kitarolja a forrás tarlabdát, belép 

a könyvtárba és megfelelően beállítja a $WORKDIR mun- 
kakönyvtár környezeti változót. Másrészről, ha valami 
szokatlan dolgot is kell csinálni, például egy foltot kell 
feltenni- magunk is létrehozhatjuk az egyszerű kicsoma- 
goló függvényt: 


src unpack O ( 
unpack $(Al 
epatch $íFILESDIRj/fixit.patch 


Végül nézzünk egy teljes példát. Volt egy ügyfelem, amely 
igen sokat használta az SSH2 protokoll ssh.com által készí- 
tett változatát. Ezért aztán sok gépre kellett feltelepítenem. 
Lásd az 1. listát. 

Az ebuild néhány környezeti változó beállításával kezd: 


e  SLOT: ezeket általában a programkönyvtárakhoz hasz- 
náljuk. Amikor az ebuild szerzője tudja, hogy ugyan- 
azon csomag különféle verziói lehetnek fenn egy idő- 
ben a gépen, egy ,slot"-szám hozzárendelésével tehet 
különbséget közöttük. Az egyik rendszeremen fenn 
van a Berkeley DB 1.85-ös verzió (SLOT 1), a 3.2.9-es 
verzió (SLOT 3), a 4.0.14-es verzió (SLOT 4) sőt még 
a 4.1.25 pl-es verzió is (SLOT 4.1). Elég sok program 
létezik, amit a régebbi API-hoz fejlesztettek, és nincs 
semmi okunk rá, hogy ezeket ne engedjük telepíteni. 
Amikor aztán a 4.0-ás sorozatban megjelenik egy újabb 
stabil kiadás, mondjuk a 4.0.17-es verzió, amíg a SLOT 4- 
et használjuk hozzá, a többi verzió eltávolítása nélkül is 
nyugodtan frissíthetek a 4.0.14-esről. Valójában a Berke- 
ley DB ennél valamivel összetettebb példa, de jól bemu- 
tatja a Gentoo , slot" elképzelésének erejét. A legtöbb 
ebuildnek persze semmi ilyesmire nincs szüksége és 
a SLOT-"0" értéket használja. 


8  KEYWORDS: itt jelezhetjük a támogatott architektúrákat. 
A példában azt mutatom be, hogy ez az ebuild az x86 
sorozaton működőképes és elismerten stabil. A - in 
-ppc azt jelzi, hogy ezek maszkoltak. Tudom, hogy 
a korábbi verziók lefordultak a PowerPC rendszeren, 
de nem áll rendelkezésemre egy sem amin kipróbál- 
hatnám, ezért másoknak óvatosnak kell lenniük, 
ha ezt a verziót választják. A hivatalos Portage fában 
az ilyen ebuild-ek néhány hétig ebben az állapotban 
lehetnek, míg a PowerPC használók ki nem próbál- 
ják azt. Néhány pozitív jelentés után az ebwild 
maszkolatlanná válik. 


e — DEPEND, RDEPEND: itt soroljuk fel a függőségeket. 
Viszonylag teljes nyelvtant és a csomagverziók listáját 
adhatjuk meg itt. A leggyakoribb módosítók: a 5 —, 
amely azt jelenti, hogy legalább ilyen verziót kell telepí- 
tenünk, általában valamilyen API miatt amitől a progra- 
munk függ; valamint a !, amit akkor használunk, ha az 
adott csomag jelenléte ütközik egy másikkal. Mindket- 
tőt tehát nem telepíthetjük egy időben. 
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RDEPEND: futásidejű függőségek, ezeket a dolgokat 
telepítenünk kell a csomag használatához. A DEPEND 
a felépítéshez szükséges függőségeket tartalmazza; 
a különbség csak akkor mutatkozik meg, ha máshol 
fordított bináris csomagokat telepítünk. 


RESTRICT: itt a Portage képességeinek finomhangolá- 
sát végezhetjük el. Esetünkben, mivel saját készítésű 
ebuild csomagról van szó, a nomirror segítségével 
meg tudtam mondani az emerge-nek, hogy ne keres- 
géljen a Gentoo tükrein. Ez önmagában még nem je- 
lenti azt, hogy nem használhatom a fejlesztők tükreit. 
Tulajdonképpen, ha vetünk egy pillantást a SRC URI 
változóra, látni fogjuk, hogy egy hozzám közel eső 
tükröt írtam ide, ahonnan a szükséges .tar.gz 
állományoka le lehet tölteni. 


Ezek után elkezdhetjük felülírni a csomag építését vezérlő 
függvényeket. A minket érdeklő rész az src compileO 
függvény lesz. Fogtam a fenti példát és csinosítottam egy 
kicsit. Láthatjuk, hogy néhány lehetőséget a USE változók 
szabályoznak, míg másokat mi adunk meg, mint például, 
hogy hol szeretnénk a beállításfájlokat elhelyezni. A leállási 
hiba (die) üzenetekre nem igazán van szükségünk, viszont 
jól mutatja, hogy a héjprogramok minden képességét és 
erejét ki tudjuk használni. 

Végül, az src install O függvény helyett is használhattuk 
volna az alapértelmezettet, de az én rendszeremen az 
/etc/init.d állományainak végén nem volt .rc utótag. Ennél 
is fontosabb, hogy ennek a parancsfájlnak az OpenSSH-t 
kellett lecserélnie a célrendszereken. Ezért biztos akartam 
lenni benne, hogy az RC parancsfájl semmiképp sem 
ugyanaz, mint ami az OpenSSH-t indítja. 

A Portage gazdag segítő-függvény készlettel rendelkezik 
amelyek egyszerűsítik az gyakran szükséges feladatokat. 
Az egyiket ki is használjuk, amikor megmutatjuk hová 

kell kerülnie az RC parancsfájlnak majd ellenőrizzük, hogy 
végrehajthatónak van-e kijelölve. Ezek után az ebuwild-et 

a helyi Portage fa másolatunkba helyezve és kiadva az 
emerge parancsot végrehajthatjuk a lépéseket. 

Példánk tulajdonképpen csak a felszínt karcolgatja. 

További részleteket találunk a 5 www.gentoo.org/proj/en/ 
devrel/handbook/handbook.xml?part-26chap-—1itdoc chap2 
lapon illetve bármely Gentoo rendszeren az emerge --help 
kimenetében vagy az ebuild(1) és ebuild(5) kézikönyv- 
oldalain. 


Több gép karbantartása 

Képzeljük el ugyanezeket a problémákat egyetlen gép 
helyett több tucat kiszolgálóval és munkaállomások ez- 
reivel felszerelt termelési környezet esetében. Nem túl 
sok operációs rendszert találunk amely segíthet ilyenkor. 
Sok polcnyi irodalom foglalkozik az infrastruktúra keze- 
lés témájával. Sajnos még mindig elég sok ad-hoc megol- 
dással találkozhatunk. Bár sok gyártó forgalmaz olyan 
eszközöket, amelyekkel kezdetben tömegével telepít- 
hetünk rendszereket, azonban a későbbi karbantartás 
feladatát általában a felhasználóra hagyják. Az új verziók 
problémája nem csak egyetlen gépen jelentkezhet, 

egész hálózatokat is sújthat. 
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Tehát hogyan is kerül a Gentoo a termelési környezetbe? 
Itt jön a forrás alapú terjesztés második meglepetése: 

a Portage képes bináris csomagokat is készíteni. Ezzel 
lehetővé válik, hogy a sarokban felállított egyetlen gép 
végezze az összes fordítási munkát. Az összes több gép 
ezeket a bináris csomagokat használhatja, így nem kell 
maguknak lefordítani a csomagokat. Sokan biztos azt 
kérdezik magukban , de hát nem éppen ezt teszi a többi 
Linux terjesztés is?" A különbség abban rejlik, hogy itt 

a helyes csomag-összeállítás kiválasztása a helyi dönté- 
sektől függ, és egy újabb verzió alkalmazása egyértelmű- 
en olyasmi, amit helyben kell megoldani. A Gentoo a z 
adott rendszercsapatnak olyan eszközöket ad a kezébe, 
amelyekkel maguk megoldhatják is az ehhez kapcsolódó 
különféle problémákat. 

Egy fordítókiszolgáló alkalmazásával az erőinket és 

a verziókezelést hatékonyan koncentrálhatjuk, ugyan- 
akkor mégis helyet biztosítunk a helyi sajátosságoknak. 
Könnyedén összeállíthatunk egy ilyen lépcsős rend- 
szert. Aztán, amikor meg vagyunk elégedve a tesztelt 
verziókkal, egyszerűen pillanatképet készítünk a biná- 
ris csomagokról majd kiosztjuk őket a sorkatona gépe- 
inknek. A Portage újabb verziói beépített lehetőséggel 
rendelkeznek a helyi fájlkiszolgálón készült bináris 
csomagok letöltésére, így az egész megoldást kulcsra- 
készen kapjuk. 


Osszefoglalás 

Saját csomagunk készítése vagy egy már létező csomag kézi 
verzió javítása folyton gondokat okoz. Az tűzhöz közelebb 
álló csomagkezelők, jóllehet kiforrottabbak, sokkal több ne- 
hézség árán képesek csak végrehajtani ezeket a feladatokat. 
Elméletileg a feladatok egyszerűek. Legnagyobb meglepeté- 
semre, hiszen ezt az oldalát nem is reklámozzák a dolog- 
nak, a Gentoo eszközeivel magunk is könnyedén megold- 
hatjuk ezeket a problémákat. 
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Adatbázisok és naptárak 


Az iCalendar szabványt már megismertük, most itt az ideje, hogy az adatokat 
adatbázisból vegyük, és a naptárakat futásidőben állítsuk elő. 


múlt hónapban folytattuk az ismerkedést 
A az iCalendar szabvánnyal, amelyre alapozva 

a programok naptár- és találkozóadatokat 
cserélhetnek egymással. Mint láttuk, egy iCalendar fájl 


egy vagy több eseményt és feladatot, tennivalót tárolhat. 


Ha a fájlt elérhetővé tesszük egy http kiszolgálón, 
például Apache-on keresztül, akkor bárki számára 
terjeszthetjük, aki az iCalendar kezelésére alkalmas 
programmal rendelkezik - ilyen például a Mozilla 
Sunbird. Amint a múlt hónapban láttuk, ennél eggyel 
tovább is léphetünk, és az iCalendar fájlt dinamikusan, 
CGI programmal is előállíthatjuk. 

A múlt hónapban bemutatott programokat ugyan bizo- 
nyos körülmények között lehet hasznosítani, az minden 
webes fejlesztő számára egyértelmű, hogy a dátum- 

és időadatokat a programon belül tartani finoman szólva 
ostobaság volna. 

Az ilyen adatok tárolását a legjobban relációs adatbázis- 
ban oldhatjuk meg, például PostgreSOL segítségével. 
Relációs adatbázis alkalmazásával könnyebb biztosíta- 
ni a bevitt adatok érvényességét, továbbá gyors és 
rugalmas hozzáférést kapunk az elmentett adatok 

egy részéhez vagy egészéhez. További előny, hogy ha 

a naptáradatokat adatbázisban tároljuk, akkor ugyanazt 
a forrást használva egy-egy naptárfájlból több változatot 
is elő tudunk állítani. 

Ebben a hónapban egy egyszerű, web alapú programra 
fogunk példát nézni, mely relációs adatbázisból veszi 

a naptáradatokat, ezek alapján előállít egy iCalendar 
adatfájlt, ami viszont alkalmas lesz az iCalendar-ral 
együttműködő programokba - mint a már említett 
Mozilla Sunbird - történő importálásra. 


A tábla megadása 

Ha a naptáradatokat relációs adatbázisban kívánjuk 
tárolni, meg kell adnunk legalább egy táblát. Ennek 
oka az, hogy a relációs adatbázisok minden adatot 

— sokszor még a beállításokat és az állapotadatokat is — 
kétdimenziós táblázatokban tárolnak, amelyekben 

az oszlopok határozzák meg az egyes mezőket, míg 
egy-egy sor egy-egy rekordot tartalmaz. PostgreSOL 
alatt például a következő módon tudunk megadni 

egy egyszerű táblát: 
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CREATE TABLE Events ( 

event id SERIAL NOT NULL, 

event summary TEXT NOT NULL 
CHECK (event summary c ""), 

event location — TEXT NOT NULL 
CHECK (event location cs ""), 

event start TIMESTAMP NOT NULL, 

event end TIMESTAMP NOT NULL, 

event timestamp TIMESTAMP NOT NULL 
DEFAULT NOWCO) , 

PRIMARY KEY(event id) 
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A fenti tábla hat oszlopot tartalmaz. Az első az event id 
(eseményazonosító), típusa SERIAL. Ha az event. id-nek 
nem adunk kifejezett értéket, amikor hozzáadunk egy-egy 
sort a táblához, akkor a PostgreSOL önműködően vesz egy 
legfeljebb 2" értékű egész számot. A PostgreSOL nagyobb 
felső határ megadását vagy az 1-es értékhez való körbefor- 
gást is lehetővé teszi, erről részletesebb tájékoztatás a leírá- 
sában található. 

Az event. id oszlop tartalma egyedileg azonosítja 

a tábla sorait, ezt a PRIMARY KEY (elsődleges kulcs) 
kulcsszó (vagyis inkább kulcskifejezés) tudatja az 
adatbázissal. Ez nemcsak a rekordok lekérdezéséhez 
szükséges oszlopot adja meg a többi adatbázis-prog- 
ramozónak, de az értékek egyediségét és az oszlop 
indexelését is biztosítja. 

Szintén automatikusan kap értéket az event timestamp 
(esemény időbélyeg). A megadásból látható, arra is van 
mód, hogy explicit értéket adjunk neki (ezt meg is fogjuk 
tenni), de alapértelmezett értéke az aktuális idő. Az általá- 
nos az, hogy ha ilyen formában adunk meg egy oszlopot, 
akkor explicit értéket csak kivételes alkalmakkor kap, és 

a legtöbb esetben a PostgreSOL-re bízzuk feltöltését az 
aktuális dátummal és idővel. 

Megjegyezném, hogy az event. summary (esemény összeg- 
zése) és az event location (esemény helye) egyaránt TEXT 
típusú (vagyis ezek végtelen hosszúságú, szöveges mezők), 
míg az event. start (esemény kezdete), az event. end (ese- 
mény vége) és az event. timestamp (esemény időbélyege) 
TIMESTANP (időbélyeg) típusú; az SOL-ben ez a szabványos 
megoldás dátum és idő megadására. 


2005. augusztus 99 


0 Kiskapu Kft. Minden jog fenntartva 


0 Kiskapu Kft. Minden jog fenntartva 


1. kódrészlet db-calendar.py 


í1!/usr/bin/python 

f A CGI modul beemelése 

import cgi 

import psycopg 

from icalendar import Calendar, Event 
from datetime import datetime 

from icalendar import UTC í időzóna 

tf Az esetleges hibák naplózása 

import cgitb 

cgitb.enable(display-0, logdir-—"/tmp") 
ft content-type fejrész küldése 

print "content-type: text/calendarmw" 
tí Naptár objektum létrehozása 

cal - calendarO 

f Milyen termék hozta létre a naptárat? 
caladd("prodmdP , 

"-//Python icalendar 0.9.3//mxm.dk//? ) 
tf Az RFC 2445-nek a 2.0-s változat felel meg 
cal.add( "version", "2.07) 
ft Adatbázis-kapcsolat létesítése 
db connection -— 

psycopg. connect ( "dbname-atf user-reuven") 
db cursor - db connection. cursor 
db cursor.execute 
(C"""SELECT event id, event summary, 
s event location, 
event start, event end, 
ssevent timestamp 
FROM Events 
ORDER BY event start""") 
result rows - db cursor.fetchallO 
for row in result rows: 
ft Esemény létrehozása 
event - EventŐ 
í Az eseményazonosító megadása 
event["uid"] - str(row[l0]) 4 "idGATF" 
ft Leírás és helyszín megadása 
event. add( "summary", row[1]) 
event.add( "location", row[2]) 
ft A dátumok átalakítása 
event.add("dtstart", datetime(tzinfo-UTCO , 
"row jétúple0 108515D 
event .add("dtend", datetime(tzinfo-UTCO) , 
trow[4] .tupleO [0:5])) 
event .add("dtstamp", datetime(tzinfo-UTCO , 
"row[5].tupleO[0:5])) 
í Kapjon kiemelt fontosságot! 
event.add( "priority", 5) 
íf Az esemény hozzáadása a naptárhoz 
cal.add component(event) 
ft A naptár utasítása önmaga leképezésére iCalendar 
ft fájlként, majd a fájl átadása a HTTP-válaszban. 
piramt caltaszstringó 


96 Linuxvilág 


A tábla összes oszlopánál szerepel a NOT NULL (nem nulla) 
kifejezés, vagyis ezek nem kaphatják az SOL esetében 

a meghatározatlant jelentő NULL értéket. A NULL nem azo- 
nos az igazzal vagy a hamissal, ami a kezdők esetében sok- 
szor félreértéseket okoz. A NULL-t mint ismeretlen, meg nem 
adott értéket kell kezelni — így talán könnyebb. Bár a NULL 
értékek segítségével könnyen meg tudjuk különböztetni 

a hamis és az ismeretlen értékeket, használatukat érdemes 
a lehető legszűkebb körre korlátozni. Sőt, általában azt 
szokták tanácsolni, hogy alapesetben minden oszlopot NOT 
NULL-ként, vagyis nem nullként adjunk meg, és csak akkor 
engedélyezzük a NULL értékek használatát, ha az valóban 
szükséges. 

Felhívnám még a figyelmet a két szöveges oszlop megadá- 
sára (event. summary és event location), melyek egyrészt 
a NOT NULL kulcsszóval vannak ellátva, másrészt egy to- 
vábbi, az üres karakterláncok bevitelét megakadályozó 
ellenőrzés tárgyát képezik. Az, hogy ezek az ellenőrzések 
helyénvalók-e, a tényleges alkalmazási környezettől függ. 
Előfordulhat, hogy valamiért inkább engedélyezni akarjuk 
a NULL értékek használatát, és az összegzésben vagy 

a hely megjelölésében szereplő üres karakterláncok sem 
okoznak gondot. 

Bár a fenti táblamegadást csak egyszerű példának szán- 
tam, gondoljunk bele, milyen jó volna a helyszíneket 
külön táblában tárolni, például egy location id (hely 
azonosítója) és location name (hely neve) oszloppal, majd 
a szöveges event location oszlopot a location. id-vel 
helyettesíteni. Így egységesíteni tudnánk a helyszínneveket, 
vagyis maga az adatbázis is egységesebbé válna, illetve arra 
is módunk nyílna, hogy kikeressük az adott helyszínen 
várható eseményeket. 

Amikor végeztünk a tábla megadásával, hozzáadunk 
néhány indexet. Az indexek révén az adatok lekérdezése 
gyorsabb lesz a normál lekérdezéseknél; ennek az INSERT 
(beillesztési) műveletek megnövekedett végrehajtási idejé- 
vel fizetjük meg az árát. Nézzük a megadásokat: 


CREATE INDEX event location idx 

ON Events(event location); 
CREATE INDEX event start idx 

ON Events(event start); 
CREATE INDEX event end idx 

ON Events(event. end); 


Uj adatok beillesztése 

Elkészült a tábla és az indexek, kezdjük el eseményekkel 
feltölteni az adatbázist. Az események beillesztésére az 
INSERT parancs szolgál, melynek írásmódja a következő: 


INSERT INTO Events 
(event. summary, event location, 
event start, event end) 
VALUES 
("Március idusa", "Mindenhol!" , 
"2005-March-15 00:007, "2005-March-15 23:59:59") 


Mint látható, a fenti INSERT utasításban az Events tábla 
hat oszlopából csak négy szerepel. Ha megvizsgáljuk 
az új sor tartalmát, a következőt találjuk: 








atf-t select " from events; 
-[ RECORD 1 ]-—--4—-—————————————————————— 


event id [d 
event. summary Március idusa 
event location Mindenhol 


2005-03-15 00:00:00 
2005-03-15 23:59:59 
2005-04-04 01:20:15.575032 


! 
! 
event start I 
event end I 
event timestamp I] 
Mint látható, az event. id (mely, mint emlékszünk, 

SERIAL típusú) automatikusan kapott egy 1-es értéket, 

az event. timestamp pedig megkapta értékül a beillesztési 
kérés végrehajtásának időpontját. 

Könnyű elképzelni, hogyan hívnánk meg az INSERT utasí- 
tást valamilyen web alapú programból, például CGI-n, 
esetleg valamilyen fejlettebb rendszeren keresztül, mint 

a mod perl vagy a Zope. Hozzátenném, az adatbázisba 
befutó adatok beérkezésének módjával sem kell foglal- 
koznunk, különösen, ha megadtuk a megfelelő megszorí- 
tásokat. Nyugodtan feltételezhetjük, hogy az adatbázisban 
található adatok megbízhatóak, és a kiszolgáló eleve elutasí- 
totta az előírásoknak meg nem felelő beviteleket. 


Dinamikus iCalendar fájl létrehozása 

Ha már van néhány eseményünk az adatbázistáblában, 
megpróbálhatjuk lekérdezni őket egy CGI programból. 

A program kimenete iCalendar formátumú lesz, vagyis az 
iCalendar ügyfelek is hozzáférhetnek majd az adatokhoz. 
Az 1. kódrészlet egy ilyen programot tartalmaz, ez egyébként 


a múlt hónap dynamic-calendarpy programjának módosí- 
tott változata. Mint a múltkor már utaltam rá, a programot 
nem kis részben azért Pythonban írtam, mert viszonylag 
szűkében állunk az iCalendar formátumú fájlok előállítására 
használható moduloknak. Szerencsére Python alá van ilyen 
modul, és én nem voltam rest kihasználni ennek előnyeit. 
Mint az 1. kódrészletből is látható, semmi bonyolultra 
nem kell számítani. Beemelünk néhány modult, létrehozunk 
egy naptár objektumot, majd beillesztjük az iCalendar szab- 
vány által megkövetelt mezőket, megadva a naptár forrását. 
Ez után csatlakozunk egy a feltételezésünk szerint 
a helyi gépen futó PostgreSOL kiszolgálóhoz. Bár Python- 
PostgreSOL párosításhoz több adatbázis-csatoló is létezik, 
én a psycopg-t használom, mely gyors és üzembiztos. 
A PostgreSOL-hez a psycopg segítségével a következő írás- 
módot alkalmazva kapcsolódhatunk: 
db connection - psycopg. connect 

( "dbname-atf user-reuven? ) 


A fentiek szerint az adatbázis neve atf, a felhasználónév 
pedig reuven. További lehetőség a kiszolgáló és valamilyen 
jelszó megadása, amire inkább akkor lehet szükség, ha éles 
rendszeren dolgozunk. 

Miután csatlakoztunk az adatbázishoz, veszünk egy muta- 
tót, ezzel tudjuk elküldeni a kéréseinket és lekérdezni az 
eredményüket: 


db cursor - db connection. cursor() 








Értékeld a Linuxvilág 
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Szaktekintély 
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Kezünkben a kurzorral immár tudunk SOL-lekérde- 
zéseket küldeni az adatbázisnak; ezeket a Python ,három 
idézőjeles" írásmódját kihasználva tettem könnyebben 
olvashatóvá. A következő lépés az eredmények lekérése. 
Ha nagyobb számú, akár több száz találatra számítanánk, 
akkor célszerűbb volna egyenként, esetleg csoportok- 
ban lekérni őket, ez esetben azonban tudjuk, hogy nap- 
tárunk mindössze néhány eseményt tartalmaz, ezért 

a fetchal1O hívással egyetlen lépésben lekértem 

az összest. 
result rows - db crsor.fetchallO 

A result. rows (eredmény sorok) minden egyes eleme 
egyegy sor a PostgreSOL adatbázisból. Ha tehát egy for 
ciklussal végiglépkedünk a sorokon, akkor megkapjuk 

a találat egyes elemeit. 

A legtöbb esetben az egész eljárás rutinműveletnek szá- 
mít, ám amikor dátumokkal és időpontokkal dolgozunk, 
már több figyelmet kell szentelnünk az adatkezelésnek 

— márpedig a dátumok a naptár fontos elemei. A gond az, 
hogy a psycopg az eGenix.com nyílt forrású mxDateTime 
modulját használja, amellyel rendkívül könnyű a dátu- 
mokat kezelni. Csakhogy az mxm iCalendar modulja 

a Python datetime modulját használja, ami viszont eltérő. 
Le kell tehát kérdeznünk az egyes dátumokat (az egyes 
események kezdő és záró dátumát), mxDateTime példány- 
ból datetime-megfelelő tuple-é kell alakítanunk őket, 
majd a tuple felhasználásával elő kell állítanunk egy 
datetime-példányt, amelyet már át tudunk adni az 

event . add-nek: 


event.add("dtstart", datetime(tzinfo-UTCO) , 
event. add("dtend", datetime(tzinfo-UTCO , 
"row[3].tupleO [0:5])) 


A fenti három sornyi kódban a datetime() második 
átadott értéke pontosan az imént felvázolt eljárást hajtja 
végre. A kapott sorból vesz egy oszlopot, majd tuple-é 
alakítja. Ezután fogjuk a sorozat egy darabját (a Python 
kényelmesen használható [0:5] írásmódjával), ezzel 
hozzájutunk a tupleO) által visszaadott elemek egy 
részhalmazához. 

A datetimeO -nak viszont nem lehet sorozatot átadni, 
csak különálló elemek sorozatát. Másként fogalmazva, 

a datetimeO több számot vár, és nem hivatkozást vagy 
mutatót számok egy listájára. A tuple-t a Python " operáto- 
rával bontjuk önálló elemekre. Végül, az élesebb szemű 
olvasók bizonyára észrevették, hogy a tzinfo átadott érték 
még a tuple elemei előtt szerepel, ennek oka az, hogy 
Pythonban a nevesített átadott értékeket még a " operátor 
előtt kell megadni. 


További lehetőségek 

A db-calendar.py futtatásával az iCalendar szabványnak 
tökéletesen megfelelő, a Sunbird vagy más naptárprogram 
alá gond nélkül importálható fájlt kapunk. Emellett, 

ha elvégzünk egy egyszerű módosítást az Events táblán, 
biztosíthatjuk, hogy a naptárra feliratkozó felhasználók 
mindig a legújabb változatot kapják meg. 
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Ennél tovább is mehetünk, érdemes például a db- 
calendar.py-t úgy módosítani, hogy kimenetében csak 
bizonyos események szerepeljenek. Lehetséges például, 
hogy megelégszünk a jövőbeli események átadásával, és 
nem terheljük mások naptárát (és sávszélességét) a múlt 
történéseivel. Ilyenkor elég egy egyszerű WHERE utasítást 
adnunk az SOL-lekérdezéshez, és a már megtörtént esemé- 
nyeket könnyedén kiszűrhetjük. 

Ennél érdekesebb lehetőség a különféle naptárbeli csoportok 
és elérési szintek elkülönítése. A HTTP támogatja a felhasz- 
nálónév és jelszó alapú hitelesítést, és bár a Sunbird jelenleg 
nem teszi lehetővé az ilyen jellegű védelem alkalmazását, 

a jövőben várható ez irányú továbbfejlesztése (ahogy a többi 
programé is). Figyelembe véve, hogy a CGI programok 
könnyen meg tudják határozni a hitelesített HTTP kérések- 
hez tartozó felhasználónevet, talán nem túlzás azt mondani, 
hogy a db-calendar.py a különböző felhasználók számára 
különböző kimeneteket is elő tudna állítani, a hozzárendelt 
engedélyek és szerepek alapján. 

Végül utalnék rá, hogy bár az elmúlt hónapokban az 
iCalendar formátumra összpontosítottunk, nincs semmi oka 
annak, hogy az adatbázis tartalmát kizárólag iCalendar fájl- 
ként tegyük elérhetővé. Miért ne tehetnénk meg például, 
hogy az iCalendar mellett a jó öreg HTML formátumban is 
megjelenítjük az eseményeket? HTML táblázatok segítségé- 
vel roppant egyszerű volna a feladat megoldása - ez is ki- 
váló példája annak, hogy relációs adatbázisra támaszkodva 
az adatok különféle formátumokban való megjelenítése 
nem probléma, sokkal inkább lehetőség. 


Összefoglalás 

Röviden áttekintettük, hogyan alkalmazhatunk adatbázist 
az események adatainak tárolására, amelyek alapján végül 
iCalendar-megfelelő fájlt állítottunk elő. Adatbázis haszná- 
latával nemcsak a tárolt adatok megbízhatóságát növelhet- 
jük, de könnyen és gyorsan állíthatunk elő dinamikus, 

az iCalendar formátum olvasására képes programok által 
kezelhető fájlokat. 
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FreeBSD - a szomszéd vár (10. rész) 


A vár őrei 


Egy kiszolgáló gép elsődleges feladata, hogy a kliensek kéréseit kiszolgálja, 
s eközben meg kell különböztetnie a klienseket a támadóktól. A BSD vár önma- 
gában elegendő bizonyos fokú védelemre, azonban ezt érdemes kibővíteni. 


Betörési pontok 

Több támadási típusra kell felkészülnünk, amelyek 
gyakran szolgálnak betörési útként különféle támadók- 
nak, legyenek humán betörők, vagy jól megírt programok 
(férgek vagy vírusok). 

A szolgáltatásmegtagadás (Denial of Services, DoS) célja, 
hogy elfogyassza a gépünk egyes erőforrásait, amelyek 
fontosak az üzemszerű működéshez. Többnyire nyers 
erőt felhasználva annyi kérést zúdítanak a célzott gépre, 
hogy az képtelen lesz a kiszolgálásra, esetleg össze is om- 
lik. Kisebb arányt képviselnek azok a támadások, amelyek 
egy szolgáltatás programozási hibáját kihasználva egyet- 
len hálózati kérést küldenek csupán, s ez már elegendő 
arra, hogy akár a kiszolgáló is a padlóra kerüljön. 

Ez utóbbi esetben az adott szolgáltatás vagy a rend- 
szermag hibáját kijavítva a DoS lehetősége megszűnik. 

Az előbbi esetben érdemes korlátozni az egyes szolgál- 
tatások által használható erőforrásokat, így a DoS csak 
ideiglenesen jár sikerrel. 

A felhasználói jog szerzése sokkal gyakoribb és elterjed- 
tebb támadási mód. Sok olyan szolgáltatás fut még, 

amely a felhasználói adatokat (név és jelszó) titkosítás 
nélkül küldi és fogadja (FTP, POP3, stb). Ezeket az in- 
formációkat a hálózati forgalom figyelésével könnyedén 
le lehet jegyezni, s később felhasználni. Egy bizonyos 
felhasználói számot túllépve a rendszergazda már nem 
lesz képes kideríteni, hogy valóban az adott felhasználó 
lépett be egy késő esti órában dolgozgatni, vagy sikeresen 
ellopták az adatait. 

Előfordulhat, hogy a root felhasználó nevében sikerül 
belépnie a támadónak, akár egy hibás program biztonsági 
hiányosságát kihasználva, akár a jelszó figyelésével. Szá- 
molnunk kell azzal, hogy a rendszergazdai jogok birtoká- 
ban könnyedén eltávolíthatja a betörés és az adatlopás 
nyomait. Ritka eset, amikor a támadók összeomlásra készte- 
tik a kiszolgálót magát, gyakoribb, hogy hátsó ajtót hoznak 
létre, s azon már észrevétlenül képesek közlekedni. A hátsó 
kapuk gyakorta más gépek feltöréséhez adnak rejtőzési 
lehetőséget a profi adatgyűjtők számára. 
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Alapvető biztonság 

Ha nem tesszük biztonságossá a root hozzáférést, 
akkor felesleges dolgoznunk a többi alrendszer bizton- 
ságossá tételén, a támadóknak tálcán kínáljuk rendsze- 
rünk leginkább áhított gyenge pontját. A legtöbb ki- 
szolgáló esetén nem fontos a root hozzáférést konzolon 
kívül hozzáférhetővé tenni, ezen túllépve még akár 

a konzolon is megtilthatjuk, s így csak egy meghatáro- 
zott felhasználón át tudunk rendszergazdai jogokhoz 
jutni, mégpedig a su parancsot használva. A távoli 
hozzáférést a /etc/ttys állományban tudjuk korlátozni, 
így az általános programokat tekintve (telnet, rlogin, 
stb.) már kizártuk azon próbálkozásokat, amelyek 
egyenesen a root felhasználó jogaival szeretnének 
bejutni. Egyéb esetben a programok és szolgáltatások 
saját beállításaival tudunk még sikereket elérni: 
például az SSH esetén a /etc/ssh/sshd. config állo- 
mányban a PermitRootLogin változó értékét állítsuk 
No állapotra. 

Ha sikeresen megtiltottuk a közvetlen rendszergaz- 
dai belépéseket, akkor sajnos eléggé jól elvágtuk 
magunkat a szervertől hálózaton át: ugyanis akárki 
nem lehet a su parancs segítségével rendszergazdai 
jogok birtokosa: 


tomy66Üszerver - $ su - 
su: Sorry 


A su parancs ugyanis azonnal visszautasítja a root jogok 
felé irányuló kéréseket, még a jelszót sem kéri el. A FreeBSD 
külön csoportban kezeli azon felhasználókat, akik képesek 
rendszergazdai jogokat szerezni: a wheel csoport szolgál 
erre a célra: 


tomy66(Üszerver - $ grep wheel /etc/group 
wheel : ":0: root , auth. gabor , franko 


Ha az aktuális felhasználó nincs a megadott cso- 
portban, akkor sajnos (illetve szerencsére) nem lehet 
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belőle rendszergazda az adott gépen. A csoportba tartozó 
felhasználókat viszont jelszó ellenében már közel engedi 
a tűzhöz: 


auth.gabor€szerver - $ su - 
Password: 


Ezzel a módszerrel az adott felhasználó(k) képesek lesznek 
belépni a kiszolgáló gépre, s a saját jelszavukat megadva, 
majd a root jelszót megadva már rendszergazdai joggal bír- 
nak. Sajnos azonban mind a két jelszót be kell gépelni a bil- 
lentyűzeten, így az kifigyelhető és felhasználható betörési 
célokra. Ennek okán érdemes a SSH esetén az adott felhasz- 
náló jelszavát megszüntetnünk (nem üresre állítanunk!). En- 
nek módja egyszerű, a vipw parancs segítségével szerkeszt- 
jük a passwd állományt (gyakorlatilag a /etc/master.passwd 
állományt látjuk ekkor), majd a megfelelő felhasználónévnél 
az alábbi sort 


auth.gabor : $1$tLIpY8GZ$HOPOAcZ3egNyladsR1xmgB1: 1001: 
et 10015:0:OJAUth 
Gábor : /home/tanar/auth. gabor : /usr/1ocal/bin/bash 


így módosítjuk: 


auth.gabor:":1001:1001: :0:0:Auth 
5 Gábor : /home/tanar/auth. gabor : /usr/1]ocal/bin/bash 


A beírt és kódolt jelszó soha nem lesz azonos a " karakter- 
rel, így tetszőleges jelszóval sem lehet majd belépni ezzel 

a felhasználóval. Kell készítenünk egy kulcspárt (egy privát 
és egy publikus kulcsot), mégpedig az ssh-keygen parancs 
segítségével. A publikus kulcsot hozzá kell másolnunk 

a kiszolgáló gép felhasználójának .ssh könyvtárában lévő 
authorized keys állományához. A kliens gép .ssh könyvtárá- 
ba pedig a privát kulcsot kell őriznünk, identity néven. 

Ha be szeretnénk lépni SSH-n keresztül a kiszolgáló gépre, 
akkor az SSH nem lesz képes jelszavas azonosításra, hiszen 
bármilyen jelszót is írnánk be, az nem lesz megfelelő. Ellen- 
ben a kulcspáron alapuló hitelesítés működik, így ha az 
identity állományban lévő privát kulcsból előállított 
publikus kulcs megtalálható a kiszolgáló authorized keys 
állományában, akkor jelszó és kérdés nélkül be fog enged- 
ni. A feladatunk mindössze annyi, hogy ne engedjük ki 

a kezünkből a privát kulcsot: 


$ ssh auth.gaborGszerver 
Last login: Thu Jun 30 09:31:28 2005 from kliens 
szerver:- $ 


Mindig csak annyi szolgáltatást futtassunk, amennyi szük- 
séges; s mindig figyeljünk oda az újabb verziókra, hibajaví- 
tásokra. Egy régen frissített szolgáltatás akár egy széles és 
egyenes út lehet a támadók számára, hiszen lehetnek ben- 
ne biztonsági hiányosságok. Figyeljük rendszeresen a biz- 
tonsági értesítőket, hiszen órákon is múlhat rendszerünk 
épsége. Ha megállapítottuk, melyek a szükséges szolgálta- 
tások, akkor lehetőleg mindegyiket tegyük egy jail által 
létrehozott , homokozóba" (sandbox). Ezek a , homokozók" 
nem jelentenek túl nagy biztonságot, azonban a támadók 
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először ezekbe kerülnek, és innen is tovább kell jutniuk 

a rendszerünk belső részei felé. Törekedjünk minél több 
ilyen réteg elkészítésére, így egyre több időt kell a támadók- 
nak a rendszer megismerésével és feltörésével eltöltenie, 
így a mi rendszerünk egyre kevésbé lesz vonzzó számukra. 
A FreeBSD operációs rendszer sok szolgáltatást alapból ho- 
mokozóban futtat (stalkd, fingerd, stb.), így ezekkel nem 

is kell törődnünk. További hibaforrás a SLIID/SGID bitekkel 
ellátott programok telepítése, mivel az ezekben előforduló 
hibák automatikusan rendszergazdai jogokat biztosítanak 

a felhasználók számára. Jól jegyezzük fel, hogy ezen prog- 
ramok közül mennyit telepítünk fel, illetve ezek hol találha- 
tók: ha a méretük megváltozik, akkor annak komoly követ- 
kezményei lehetnek. 


Kiterjesztett biztonság 

Amint az alaprendszert biztonságossá varázsoltuk, még 
közel sem végeztünk a munkával. A FreeBSD programte- 
lepítésének alapja a ports adatbázis, amely már 12.000 
programcsomag felett tart. Éles rendszer esetén több 
problémával is szemberülhetünk a ports használatával, 
amelyek közül az egyik nagyon lényeges: nem értesülünk 
az újabb csomag kibocsátásának okáról. Egy egyszerű 
portupgrade végrehajtásakor az összes változott csomagot 
frissíthetjük, ám a ,Ha működik, ne javítsd!" aranysza- 
bályt ezzel csúfosan megszegjük. Többnyire nincs 
probléma, mivel az újabb programcsomag kompatibilis 

a régebbivel, ha azonban akadtak kisebb változtatások, 
akkor hamar és sürgősen kellett a hibát kijavítani 

(vagy visszatenni a régebbi verziót). 

Ezen a problémán tud segíteni a security/portaudit csomag, 
amely a periodic programon keresztül rendszeresen elvégzi 
a telepített csomagok összevetését a rendelkezésre álló cso- 
magokkal, s jelzi a csere szükségességi fokát. 

A program telepítése után azonnal kérhetünk egy jelentést 
a frissítésre váró programokról, egyszerűen a 


$ /usr/local/sbin/portaudit -Fda 


parancsot kell kiadnunk. Ezek után a program egy új adat- 
bázis letöltésével kezdi a munkáját, amely a frissítésre váró 
programok adatait tartalmazza: 


auditfile.tbz 
New database installed. 
Database created: 2005 Jún 30 Csü 18:40:13 CEST 


10057 of 26 kB 27 kBps 


Ezt követi azon csomagok felsorolása, amelyek esetén 
biztonsági okból javasolt a frissítés: 


Affected package: ruby-1.6.8.2004.07.28 1 
Type of problem: ruby -- arbitrary command 
s execution on XMLRPC server. 

Reference: chttp://ww. FreeBSD. org/ports/ 
5 portaudit/594eb447-e398-11d9-a8bd 

5 -000cf18bbe54.html- 


A felsorolt programok kapcsán kettő lehetőségünk adódik: 
frissítjük vagy eltávolítjuk őket. Egyéb esetben a rendsze- 
rünk biztonsági oldalról hibás és hiányos marad, s nyitva 











hagyjuk a kaput a támadók számára. Érdemes a program 
által kiemelt URL meglátogatása, s így bővebb információ- 
kat is tudunk szerezni a biztonsági fenyegetettségről. Eset- 
leg létezik kerülő megoldás is (workaround), amely egy 
kissé kitolhatja a kockázatos frissítés idejét, de ez többnyire 
a szolgáltatás minőségromlásával jár. 

Mivel a program minden nap lefut legalább egyszer, a fenti 
műveletekről levelet kapunk (ha olvassuk a root felhasz- 
nálónak írandó leveleket :), és így a , security run output" 
tárgyú levélben olvashatunk a telepített csomagok bizton- 
ságosságáról. 


BSD Process Accountingy 

Sok felhasználó esetén célszerű a futtatott programok 
nyomkövetése, így több napra, hétre visszamenőleg képe- 
sek leszünk lekérdezni, hogy melyik felhasználó — melyik 
programot — mennyi ideig használta. 

A Process Accounting bekapcsolásához egyszerűen 

a /etc/rc.conf állományba bele kell tennünk a 


accounting. enable-7YES" 


sort, s ezzel a következő indításkor már futni is fog 
a szolgáltatás. Az azonnali bekapcsolásához az 


$ accton 


parancsot tudjuk használni. Ettől az időponttól kezdődően 
nyomon tudjuk követni felhasználóink tevékenységét: 


$ lastcomm auth.gabor 


[581] 
kwebdesktop auth.gabor 2.22 secs Thu Jun 30 18:43 
sh auth.gabor 0.00 secs Thu Jun 30 18:41 
[sa] 


átnézni, és a szükséges programokat használni, így ezzel 
is csökkentjük a biztonsági fenyegetettségeinket. 


Auth Gábor (auth.gaborXDenaplo.hu) 
ÉT Egy pécsi középiskolában informatikát és prog- 
ramozást oktat. Tíz éve botlott először a UNIX 
rendszerekbe, 7 év Linux használat után kapta 
el a FreeBSD lázat, amiből máig nem tudott 


kigyógyulni. 


A FreeBSD projekt honlapja: 5 http://www.freebsd.org 


A magyar FreeBSD honlap: 5 http:/Avww.freebsd.hu 


A magyar BSD honlap: 5 http:/Avww.bsd.hu 


A kézikönyv magyar fordítása 


2 http:/Avww.enaplo.hu/FreeBSD/handbook/ 








Látogasson el hozzánk! 


Virtuális könyvesboltunk egyedülálló választékot kínál 
magyar és angol nyelvű számítástechnikai könyvekből. 





Számítástechnikai 
Szakkönyvek 


Híreink röviden: 


97 Megjelent az novemberi Linuxvilág magazin! 

s Néhány könyvünk árát lecsökkentettük! 

b Letölthető melléklet a 0uarkXPress 6 újdonságaíról 
b Fordítót keresünk teljes munkaidőre 

"7 UTÁNVÉTES RENDELÉSEK TELJESÍTÉSE 


Ajánlatunk: 
Megjelent! 


ne A könyv megmutatja , hogyan erősíthetjük meg vállalatunk rendszerének védd 


Photoshop es 


Flash MX 2004 


használatát 


Dátum: 2004 szei 


SSN hogyan tarthatjuk biztonságban a létfontosságú adatokat, és hogyan bővítheti 


4 gyekorathen 


kedvezmény 
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hálózat szolgáltatásait az SSH üzembe helyezésével. 
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Programfejlesztés az eFluid segítségével 


Sorozatunk utolsó fejezetében egy egyszerű programot fogunk elkészíteni 
az eFltk grafikus fejlesztőeszközének segítségével. 


yakran előfordul, hogy bizonyos ablakkezelő 
éa alkalmazások használata közben egyszerű módon 

szeretnénk elindítani alkalmazásokat. Hasznos 
segédprogram lehet egy alkalmazások indítására alkalmas 
program, amely tárolja a korábban futtatott programok 
nevét, majd a következő indításnál már egy listából is 
kiválaszthatjuk a megfelelő elemet. A kész program képe 
az 1. ábrán látható. 
Mielőtt egy programot elkezdünk fejleszteni, mindenkép- 
pen érdemes néhány mondatban megfogalmazni, hogyan 
kell annak működnie. Jelen esetben célunk egy olyan 
program elkészítése, mely megkönnyíti egy egyszerű 
ablakkezelő futtatása mellett más programok indítását. 
A programot saját magamnak készítettem, az IceWM 
ablakkezelő , Futtatás..." menüpontjának megvalósítására. 
Ebben az ablakkezelőben a programok indítására alkal- 
mazható bármilyen program, melyet a konfigurációs 
állományban megadunk az ablakkezelőnek. Elsődleges 
célom, hogy a program könnyen érthető legyen és emel- 
lett megvalósítsa a kitűzött célt. 
A példában szereplő program kétféle fő funkciót valósít 
meg. Elsősorban az alsó mezőben megadott programot 
fogja elindítani, majd amennyiben az nem szerepel a felső 
listában, kilépés előtt tárolja az új listaelemmel kibővített 
programlistát. Ha nem írunk be semmilyen új programot 
a beviteli mezőbe, akkor a listából kiválasztott alkalmazást 
indíthatjuk el. A program konfigurációs állománya a fel- 
használó saját könyvtárában lévő .flrun.cfg állomány. Ebben 
az állományban minden sor egy-egy futtatható programot 
ír le. A példában szereplő program indulásakor beolvassa 
ezt az állományt, majd feltölti a listát a beolvasott sorokkal. 
A felhasználó ezután beírhat új elemet vagy választhat 
a már meglévők közül. A program felhasználói felületén 
mindössze három gomb segíti a használatot. Az alapértel- 
mezett (ENTER billentyűvel működtethető) gomb indítja 
a kiválasztott vagy megadott alkalmazást. A második gomb 
az alkalmazásból való kilépésre szolgál és a főablak bal alsó 
sarkában kapott helyet. Amennyiben a konfigurációs állo- 
mány alapállapotba állítására van szükség, ezt a műveletet 
a középső gomb (, Reset config" felirattal) segítségével 
végezhetjük el. Természetesen a Linuxban megszokott 
módon, tetszőleges szövegszerkesztő programmal is meg- 
változtathatjuk a beállításokat tároló állományt. 
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u) Run program 


Run: [xterm 8] 


Manual input: ] 


KELETT] meteteeman ] 


1. ábra Az flRun alkalmazás ablaka 


A program készítése során fontos szempont volt számomra, 
hogy bemutassam az eFltk grafikus fejlesztőeszközének 
használatát, így nem használtam más szövegszerkesztőt 
vagy fejlesztői környezetet a megvalósítás során. Mind- 
össze az eFluid-ra és egy terminál ablakra volt szükségem, 
melyben a fordítást időnként elvégeztem, majd a progra- 
mot elindítottam. 

Lássunk tehát hozzá a megvalósítás lépéseinek. Miután ki- 
alakítottuk a felhasználói felület képét, hozzunk létre egy 
új függvényt. Ez az első lépés szükséges ahhoz, hogy a fő- 
program ablakát megtervezhessük és elhelyezhessük rajta 
a megfelelő elemeket. Tehát a fejlesztőkörnyezet menüjé- 
ben keressük meg a , New" menüt és válasszuk ki a Code-: 
Function/Method menüpontokat. A megjelenő párbeszédab- 
lakban hagyhatunk mindent az alapértelmezett beállításon. 
Ezután hozzunk létre egy új ablakot a New-5 Group-: 
Window pontok választásával. Állítsuk be a méretét, majd 
kattintsunk rá kettős kattintással. Itt megváltoztathatjuk 
például az ablak háttérszínét vagy címét, de leginkább 

a ,C4 1" fülecskén lévő adatok megadása fontosabb. 

Az ablak neve ebben a példában Mainwindow és az ablak 
létrehozásakor még végrehajtandó kódrészletet az , Extra 
code" mezőben kell begépelni. A kódrészlet az 1. listában 
látható. Ez a kód fogja lekérdezni a felhasználó saját könyv- 
tárát, majd azt kiegészíti a konfigurációs állomány nevével. 
Ez a változó a homedir, mely a program futása során mind- 
végig használható. 

A hozzáadott kód utolsó sorában még a load configO 
függvény segítségével betöltjük a konfigurációs állományt 
és feltöltjük a beolvasott elemekkel a legördülő listát. 

A függvény sorai a 2. listán tanulmányozhatók a további 
kiegészítő függvények mellett. A programban mindössze 
négy különleges szerepű eljárásra van szükség. 








1. lista 


homedir-(char ")calloc(128, sizeof(Cchar)); 
homedir-getenv ("HOME") ; 

strcat(homedir, CONFIGNAME) ; 

load config(homedir) ; 


Az initializeO függvény a program indulásakor memó- 
riát foglal a listaelemek számára. A cleanupO) függvény 
tulajdonképpen ennek a memóriaterületnek a felszabadítá- 
sára szolgál továbbá a program befejeződése előtt felszaba- 
dítja a homedir változó számára foglalt memóriát is. Mivel 
a programból többféleképpen is ki lehet lépni, helyesnek 
láttam a memória felszabadítására szolgáló kódrészeket 
külön függvényben megvalósítani. 

A listában látható másik két függvény a konfigurációs 
állomány betöltésére és mentésére szolgál. A mentésre 
csak abban az esetben van szükség, ha a listában még 

nem szerepel a felhasználó által megadott program neve. 
A lista elején még néhány állandót határozunk meg, me- 
lyek megkönnyítik a program további bővítését. Kezdetben 
megelégedtem maximálisan tíz listaelem tárolásával, hiszen 
ezzel a programmal általában a gyakran használt alkalma- 
zásokat fogom futtatni. 

A legördülő lista megvalósítására az FI. choice objektumot 
használjuk majd, a kézi adatbevitelhez pedig az FI. Input 
vezérlőelemet. 

Miután elhelyeztük a vezérlőelemeket az ablak területén, 
ideje lesz a működést is megvalósítani a különféle visszahí- 
vó (callback) függvények segítségével. Mindössze a három 
gombra kell meghatározni a függvényeket. Az egyes ele- 
mekre duplán kattintva előbukkan a beállításokat segítő 
párbeszédablak, melyben minden elemnek érdemes egy 
beszédes nevet adni. A visszahívó függvények megvalósí- 
tására is ebben a párbeszédablakban van lehetőségünk. 
Kezdjük tehát a konfigurációs állomány alapállapotba hozá- 
sával. A függvény rendkívül egyszerű, mindössze egy kér- 
dező ablakban (f1. askO függvény) megerősítést kérünk 

a felhasználótól, majd annak pozitív válasza után töröljük 
a konfigurációs állományt és a listaelemeket. Az állomány 
törléséből nem származhat semmilyen hátrányunk, hiszen 
amennyiben a program indulásakor nem található ilyen ál- 
lomány, a program folytatja futását és üres listából választ- 
hatunk. A felhasználó által megadott alkalmazást kilépéskor 
a beállításokat tároló állományba írjuk, így újra létrehozzuk 
és tároljuk a beállításokat. Az állomány törlésére az 
unlinkO rutint használjuk, tehát a programunk elején 
szükséges az tinclude cunistd.h: sor megadása. A lista- 
elemek törlésére az FI. Choice objektum removeO függvé- 
nyét használjuk egy ciklusban végrehajtva. 

A megadott vagy kiválasztott alkalmazás indítására 

a ,Run program" gomb visszahívó függvényében lesz 
lehetőségünk. A függvény egy lehetséges megvalósítását 

a 3. lista mutatja. 

A függvényben elsősorban megvizsgáljuk, hogy kézi 
adatbevitel történt-e vagy a felhasználó a listából választott 
valamilyen programot. Az új alkalmazás megadásakor 
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2. lista 


fdefine MAX ELEMS 10 
ftdefine CONFIGNAME "/.flrun.cfg" 
static char "config[MAX ELEMSI; 
static char "homedir; 


void save configO ( 
TNESIE 
FILE "ofile; 
ofile-fopen(homedir, "w-"); 
ar osulejet 
fprintf(stderr, "cannot open output fileWn"); 
"return; 
3 
for Ci-0; icproglist-ssizeO; irr) ( 
if (proglist-ssizeO) ( 
FI.String str-proglist-stext(Ci); 
FDETMEECOEnes s z0SNn tehat Str) 
3 
Hi 
fclose(ofile); 
return; 


§ 


void load config(const char" confname) ( 
ame én 
FILE "infile; 
if (confname--NULL) ( 
fprintf(stderr, 
"config filename is invalidin"); 
return; 
ii 
infile-fopenCconfname,"r"); 
Tr e eeinénien et 
fprintf(stderr, "configfile not found"); 
sére tunns 
3 
for Ci-O; i-MAX ELEMS-1; i--) ( 
if (feofCinfile)) break; 
SscantCintales  szosNn e contag ia 
if (configLli]) proglist-sadd(configl[i]); 
í 
fcloseCinfile); 
return; 


void initializeO ( 

amit 1. 

for Ci-O; i-cMAX ELEMS-1; 1-4) 
config[li]-(char")callocC(128, sizeof(Cchar)); 


void cleanupO 1 
Jé 
for Ci-0O; i-cMAX ELEMS-1; i--) 
if (Cconfiglil) free(Cconfiglil); 
free(homedir) ; 


J 
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3. lista 


static void cb btOK(FI Return Button", void") ( 
char "mstr-(char ")calloc(i28, sizeof(char)); 
strcpy(mstr, proginput-svalueO); 

strcdát(mstr, (consttchat Jie0s 


// Nem adtunk meg kézzel semmit 
Úr CS ERNEMDŰMSTIS Et ALDD KEK 
system(mstr) ; 
free(mstr); 
mainwindow-:hideO ; 
// Ha meg nincs benne a listaban a program, 
// akkor fel kell vennünk 
if (proglist-ssize0 a10) ( 
if (!proglist-sfind(proginput-svalue0)) ( 
proglist-sadd(proginput-svalueO ); 
// mentjuk a listat 
save. configO; 


ij 
return; 
1 
if (proglist-ssizeO 50) ( 
FI.String str-proglist-:stext(proglist-5 
mvalueOJr e; 
"5 (CSE EYEretutrne 
system(str.c strO); 
d 
mainwindow-:hideO ; 


, 


a systemO hívással végrehajtjuk a megadott psrogramot és 
megvizsgáljuk a listaelemeket. Ha nem találjuk a legördülő 
lista elemei között az alkalmazás nevét, hozzáadjuk a meg- 
lévő elemekhez és a save configO függvény meghívásá- 
val tároljuk a beállításokat. 

Ha a listából választott a felhasználó, akkor nincs más 
tennivaló, mint kiolvasni az elem szövegét és szintén 

a systemO hívással végrehajtani a programot. Mindkét 
esetben az ablakot elrejtjük a hide) metódusának segítsé- 
gével, hiszen az eFltk fő ciklusa addig fut, amíg valamilyen 
programablak látható a képernyőn. A program tehát befeje- 
zi működését a gomb megnyomása után. 

A harmadik visszahívó függvényben egészen egyszerűen 
csak elrejtjük a fő ablakot, így a , Cancel" gomb használata 
szintén a program befejeződését eredményezi. 

Érdemes még néhány szót ejteni a főprogramról is. Az 
eFluid-ban a New-: Code-: function/method menüpontok 
választásával hozhatjuk létre a mainO függvényt. A megje- 
lenő párbeszédablakban minden beviteli mező tartalmát 
töröljük ki, hogy az eFluid tudtára adjuk, hogy a mainO 
függvény kódját szeretnénk megadni. A főprogram kódja 
mindössze a 4. listában látható néhány sorból áll. 
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4. lista 
Ant madim Cint azgeswehamossangyis 


initializeO; 
mainwindow-make windowO ; 
mainwindow-:showO ; 

EZER ÚNGE 

cleanupO ; 

return 0; 


A függvényben meghívjuk a memóriaterületek lefoglalására 
szolgáló initializeO függvényt, majd létrehozzuk és 
megjelenítjük a program ablakát. Ezután már a szokásos 
FT: :runO függvény, vagyis az eseménykezelő ciklus futta- 
tása következik. A ciklus befejeződése egyben az alkalma- 
zás futásának végét is jelenti, azonban a kilépés előtt 

a cleanupO függvény segítségével felszabadítjuk a lefoglalt 
memóriaterületeket. 

A fenti függvények megvalósítása után már nincs más ten- 
nivalónk, mint menteni a grafikus felületet és vele együtt 

a programot is. Az eFluid-dal készült alkalmazások kiter- 
jesztését érdemes .fl-ként megadni, mert a fejlesztőeszköz 
is ilyen kiterjesztésű állományokat tekint sajátjának és alap- 
állapotban ezeket jeleníti meg az állományok megnyitását 
segítő párbeszédablakban is. 

A mentést később billentyűk segítségével is elvégezhetjük, 
mégpedig a CTRL--S kombináció alkalmazásával. 

Ne feledkezzünk meg a forrásállományok elkészítéséről 
sem. Használjuk a CTRL--W billentyűket, így az eFluid 
elkészíti a teljes programunkat tartalmazó forráskódot 

és hozzáfoghatunk a program fordításához. Ennek leg- 
egyszerűbb módja, ha egy terminál ablakban kiadjuk 

a következő parancsot: 


efltk-config ---compile runapp.cpp 


Ebben az esetben a grafikus felületet runapp.fl néven men- 
tettem és így a generált programkódot tartalmazó állomány 
neve is megegyezik a mentés során megadottakkal. A pa- 
rancs hatására létrejön a futtatható állomány, amit érdemes 
megszabadítani a felesleges dolgoktól. 

Adjuk ki a 


strip -s ./runapp 


parancsot - a program könyvtárában -, hogy a futtatható 
állományt megszabadítsuk a szerkesztés során létrejött 
szimbólumoktól. A program futását ez a művelet nem be- 
folyásolja, viszont jelentősen lecsökkenthetjük a futtatható 
állomány méretét. 

Amennyiben összetett programrendszert készítünk érde- 
mes megismerkedni a kézi fordítás mikéntjével is. Amikor 
az eFltk segédprogramját használjuk látható, hogy milyen 
kapcsolókra van szükség a fordításhoz. Ezeket a kapcsoló- 
kat kiegészíthetjük tetszőleges GCC opciókkal vagy készít- 
hetünk egyszerű Makefile-t is a fordítás megkönnyítéséhez. 











u. Run program 


Run 


calctool 

Mani bluefish 
blender 
xcalc 
frozen-bubble 
efluid 





2. ábra Alkalmazás kiválasztása 


Ebben a példában néhány kiegészítő opciót is megadtam 
a fordítónak, majd az alábbi parancssor segítségével, kézzel 
fordítottam le a programot: 


gcc -o runapp -03 -funroll-loops -fexceptions 

5 -march-pentiumpro -DFL SHARED 
-I/usr/xX11R6/include -L/usr/Xx11R6/Tib -lefiltk 
5-1]X1I1 -1]Xext -1]m runapp.cpp 


A program elkészítése után ne felejtsünk el biztonsági má- 
solatot létrehozni az állományokról. 

Végül nem maradt más hátra, mint az IceWM tudtára adni, 
hogy mostantól programok futtatására ezt a programot sze- 
retnénk használni. Nyissuk meg az IceWM beállításait tar- 
talmazó —/.icewm/preferences állományt (amennyiben nem 
találunk ilyen állományt, az IceWM adatait tartalmazó 
könyvtárból át tudjuk másolni az alapértelmezett beállításo- 


kat), és keressük meg benne a Runcommand- kezdetű sort. 
Itt kell megadnunk a futtatható állomány elérési útját, majd 
az IceWM újraindítása után máris használatba vehetjük ezt 
a hasznos segédprogramot. A 2. ábrán látható az elkészült 
program működés közben. 

Ezzel végére ért az eFltk bemutatását célzó írások sora. 
Természetesen nem adhatok az adott keretek között teljes 
referenciát minden osztályról, de remélhetőleg sikerült 
ízelítőt adnom a grafikus elemkészlet lehetőségeiből és 

a vállalkozó kedvű, tanulni vágyó olvasók folytatják a kész- 
let felfedezését és használatát. Ehhez nagy segítség lehet 

a továbbiakban az Fltk dokumentációja, hiszen nem min- 
den objektumról találunk leírást az eFltk-ban. Az eredeti 
Fltk dokumentáció azonban részletesen, példákkal megvilá- 
gítva bemutatja az elemkészlet minden lehetőségét, legyen 
szó szövegszerkesztő készítéséről vagy OpenGL alapú 
három dimenziós megjelenítésről. 

A készlethez az interneten is találhatunk kiegészítő vezérlő- 
ket és számos példán keresztül elmélyedhetünk használatá- 
nak rejtelmeiben. Izgalmas felfedező utat kívánva egy kis 
időre búcsúzom kedves olvasóimtól, jó nyaralást és tanulást 
kívánok mindenkinek. 





Fábián Zoltán (dzooliofreemail.hu) 

26 éves, jelenleg oktatóként dolgozik, 
szabadidejében szívesen foglalkozik 
Blenderrel, programozással és elektronikai 
tervezéssel. Szereti a természetet, túrázást, 











úszást és a kellemes baráti társaságot. 
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A magyar Línux-barátok magazinja 


Szavazz a CD-mellékletrőlt 

Tavasszal ,Szerkeszd te is a Linuxvilágot!" felhívással egy on-line kérdőív kitöltésére kértük olvasóinkat 
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megosztott véleményt tükröztek, de így is rengeteg hasznos információval szolgáltak nekünk, A 1 
kérdőív értékelését itt találjátok. a 
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regisztráció 
elfelejtett 


Az eredmény alapján készítettünk egy tervezetet a CD-melléketre vonatkozó változtatásokra, 
ennek megvalósításáról a Ti szavazataitok szerint fogunk dönteni. Ezért kérünk mindenkit, hogy 
válaszoljon néhány kérdésre ezen az oldalon 
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Tudósítás a legnagyobb részecskekutató-intézetből 
GRUB 
ALILO trónfosztója 
" Linuxos hangstúdió 
1 Szabadforrás és muzsika tíz percben 
k percek alatt HTTP-Kiszolgálót! 
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München mégis vár az átállással a 


Nemrég ónási hírnek számított a nyilt forrású szoftverek terjedésével kapcsolatban, hogy 
München városa teljesen át kíván térni Linuxra. A város által LíMux Projektnek keresztelt átállás 
most mégis késik. A vezetőség - tartva a szoftverlicencekkel kapcsolatos problémáktól inkább 
kívár, tovább 555 











Openoffice (2) 
UHU Linux (7) 
Gimp (1) 
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Adatbázis-kezelés PHP-ben, PEAR módra 


Építkezni fogunk, mégpedig PEAR modulokból. Az első górcső alá vett — és egyben 
legfontosabb - építőkő az adatbázis-kezelés kategóriát megalapozó DB csomag. 


orozatunk előző epizódjában áttekintettük 

kedtünk az alapprogram telepítésével, majd egy 
egyszerű példán keresztül megismerkedhettünk egy előre 
elkészített modul telepítésével és használatával. A továb- 
biakban elsőként a méltán népszerű PEAR DB csomagot 
szeretném bemutatni, amely az egyik legöregebb, ennél 
fogva legjobban kiforrott elem, számos más adatbázis- 
kezelést végző modul épül rá, és igen jelentős felhaszná- 
lói táborral rendelkezik. 
A DB csomag fogalom a PEAR-t használó fejlesztők köré- 
ben. Egy olyan adatbázis absztrakciós rétegről van szó, 
amely áttetszővé teszi a modult használók számára a rend- 
szer alatt futó adatbázist: nem kell tudni, hogy milyen ki- 
szolgáló fut a gépen, nem kell ismerni a sajátosságait, és 
adott esetben még az adatbázis-kezelőt is ki lehet cserélni 
a rendszer alatt, bár ez utóbbi nem szokás. A választott 
adatbázis-kezelő a tervezés elején meghozott stratégiai dön- 
tés, nem célszerű megváltoztatni, mert a következmények 
nem ismertek pontosan. Annyiból viszont rendkívül hasz- 
nos, hogy módosítás nélkül álljunk át az adott adatbázis- 
kiszolgáló egy újabb, némileg eltérő változatára. 
A működés lényege, hogy az adatbázisunkat nem a meg- 
szokott módon, a PHP beépített függvényeivel kezeljük, 
hanem a DB osztály metódusainak hívásával, így fedve 
el előlünk a használt adatbázis-kezelőt. Ezek a metódusok 
egyrészt jópár feladatot átvesznek a fejlesztőtől, másrészt 
segítik a különböző alkalmazások, projektek egységesen 
történő felépítését. 


Lássunk egy konkrét példát! 

Egy mysgl adatbázisból szeretnénk egy egyszerű lekérdezés 
adatait kinyerni. Ehhez a következőt kell tennünk a PHP 
beépített függvényeit használva: 


$dbh - 

mysgl. connect( "kiszolgalo" , "felhasznalo? , " jelszo"); 
mysgl. select db( "adatbazis nev"); 

$res - mysgl. guery("select " from test" , $dbh) ; 

//az eredmények bejárása... 

Mindez PEAR DB-n keresztül az alábbi módon 
történik: 

$dbh -£ 
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Top Level :: Database 
Package Information: DB 





Main. Download  Documentation Bugs Trackbacks 





7 Summary 
Database Abstraction Laver PHE License 


7 Current Release 
1.7.6 (stable) was released on 2005-04-11 (changelog) 





3 Description 
DB is a database abstraction laver providing 

3 an 00-style gyery API 

" portabilíty features that méke programs written for one DBMS work with other DBMS-s 

5 a DEN (data source name) format for specifving database servers 

3 prepare/execute (bind) emulation for datebases that dort support it natively 

"a result object for each guery response 

3 portable error codes 

" segyence ermulation 

" segvential and non-seguerttial row fetching as well as bulk fetching 

"5 formats fetched rows as assodative arrays, ordered arrays or objects Í 

"4 row Imit support 

9 transactions support l 

3 table information interface 
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Package Proposals: 
s New Propozal 


Develapers: 
9 List Accounts 








1. ábra A PEAR DB csomag weboldala 


[a 
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2. ábra A végfelhasználói dokumentáció példaprogramokkal 


DB: : connect("mysagl : //felhasznalo:jelszotkiszolgalo/ 
s adatbazis nev"); 

$res -£ $dbh-sguery("select " from test"); 

//az eredmenyek bejarasa... 


(Megjegyzés: a referencia átadást végrehajtó operátorra 
(-8) csak PHP4 esetében van szükség, PHP5-ben minden 
objektum referencia formájában adódik át az egyenlőség 
operátor hatására.) 








Mint látható, minden későbbi művelet során a kapcsolatke- 
zelő ($dbh) metódusait kell meghívnia PHP függvények he- 
lyett, ezzel egy egységes adatbázis-kezelő felületet kaptunk, 
amit mindenhonnan, mindenféle adatbázis-kiszolgáló mel- 
lett ugyanúgy kell használni. 

Mielőtt részletes bemutató formájában megnéznénk, hogy 
hogyan is kell pontosan használni, tekintsük át a megoldás 
felépítését. Maga a csomag több osztályból áll, ennek leg- 
gyakrabban használt eleme a DB osztály maga, ez képviseli 
a felhasználók felé a PEAR DB-t, ezen az osztályon keresz- 
tül lehet csatlakozni, kapcsolatot bontani, lekérdezni, hibát 
kezelni, stb. Amikor egy kapcsolat felépül, a használat adat- 
bázistól függően más-más módon kell az elvégzendő műve- 
leteket leképezni. Erre szolgálnak a közvetlen adatbázis 
osztályok, amelyekből minden adatbázistípushoz (MySOL, 
PostgreSOL, Oracle, stb) pontosan egy tartozik. A tényleges 
műveletek tehát egy ilyenen keresztül zajlanak, s az értékek 
továbbadódnak a DB osztálynak, amelyik visszaadja a fel- 
használók felé. Ezek az osztályok a DB felé egyformák, 
mindet ugyanúgy kezeli a központi osztály, miután 

a kapcsolat felépítése során kiválasztotta a neki megfelelőt. 
Az egyformaságot úgy érik el, hogy minden ilyen adatbá- 
zis-függő közvetlen osztály egy azonos ősből, a DB common 
alaposztályból származik, ezáltal örökli annak tagfüggvé- 
nyeit. A már emlegetett adatbázis - 2 függő közvetlen osz- 
tály 22 DB osztály 2: felhasználó lánc legvégén (a fel- 
használó előtt) még van egy elem, ugyanis a felhasználó 
egy eredményhalmazt kap, amely itt az egyértelműség 
kedvéért szintén objektum, amely magában hordozza az 
adatok barátságos kinyeréséhez szükséges metódusokat. 

A visszaadott eredményhalmaz a DBresult burkoló 
(wrapper) osztály egy példánya. 

Ezen kívül van még pár osztály, amely az alapok elsajátítása 
szempontjából nem lényeges, ezekre most nem térünk ki, 
inkább lássuk magát a medvét! Itt is meg kell jegyeznem, 
hogy nincs lehetőségünk az összes tagfüggvény áttekinté- 
sére, így arra fogunk törekedni, hogy egy teljes, jól áttekint- 


hető , fejlesztői" folyamatot kapjunk kézhez a cikk végén. 


Első lépés: kapcsolódás az adatbázishoz 
Megszokhattuk, hogy ahányféle adatbázis, annyiféle kap- 
csolódási mód. A DB esetében ez azonban egységesítve 
van. Megfigyelhetjük használat közben is a fenti példakód 
alapján: a csatlakozáshoz egy URL-t definiál (DSN — Data 
Source Name — Adatforrás név), amellyel leírható az adatbá- 
zis típusa, helye, felhasználónév, jelszó és az adatbázis ne- 
ve, és még sok egyéb más is. A leírás kétféleképp történhet: 
meghatározott formátumú karakterlánccal, vagy meghatá- 
rozott elemeket tartalmazó tömbbel. Sajnos adatbázis típu- 
sonként eltérő lehet a megadható komponensek neve és 
száma, általánosságban csak annyit lehet elmondani, hogy 
a DSN az alábbiak szerint alakul: 


phptype (dbsyntax) : //username : passw hordáprotocol1-host 
5 spec:port/database?option-value 


A magyarázat: 


phptype: az adatbázis típusa, amelyet a php kezel 
dbsyntax: adatbázis , altípus" pl. ODBC vezérlő esetén 
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username:password: név/jelszó páros 

protocol: meghatározza, hogy milyen protokollon 
keresztül érjük el az adatbázist (tcp, unix socket, 
stb.) 

hostspec:port: Az adatbázis-kiszolgáló neve és 
portja 
database: 
option-valuegoption2-value2: kulcs érték párok, 
amelyekkel speciális paramétereket adthatunk meg 
a kapcsolat számára. 


a használni kívánt adatbázis 


A fenti példában MySOL adatbázis felett, ,root" felhaszná- 
lóként, jelszó nélkül csatlakoztunk a helyi gépen futó ki- 
szolgálóhoz, ahol a (test nevű adatbázist használtuk. 

Ha tömb formájában akarjuk megadni az adatokat, 
akkor asszociatív módon, kulcs-érték párokkal tehetjük 
meg, ahol a kulcsok a fent részletezett elemek, értékük 
pedig a behelyettesíteni kívánt karaktersorozatok. A kap- 
csolódáshoz ezután a DB osztály connect metódusát 
használhatjuk, melynek első paraméter a már emlegetett 
DSN, a második pedig a kapcsolat paramétereit rögzítő 
tömb. Ez tartalmazza például, hogy perzisztens legyen-e 
a kapcsolat, használjon-e SSL protokollt, a nyomkövetési 
üzenetek szintjét, stb. 

A sok elmélet után következzen egy kis gyakorlat, nézzünk 
egy-egy példát a karakterlánc, illetve tömb formájában 
átadott kapcsolódási paraméterekkel. 


$dsn - "pgsgl://someuser:apasswdAálocalhost/ 
5 thedb" ; 
$options -— array( 
"debug" Sz 25 
"portability?" -—5 DB PORTABILITY ALL, //minden 


eszközzel támogassa az AB-függetlenséget 


Ja 
$db -g DB: :connect($dsn, $options); 


if (PEAR::isError($db)) ( 
die(C$db-sgetMessageO ) ; 


A másik esetben a kód így néz ki: 


$dsn - array( 
"phptype" - "pgsal", 
"username? -s5 "someuser", 
"password?" -5 "apasswd", 
"hostspec" -5 "localhost", 
"database" -—-5 "thedb", 
); 
$options -— array( 
"debug" ms 2; 
"portability?" -—5 DB PORTABILITY ALL, //minden 


eszközzel támogassa az AB-függetlenséget 


B 


$db -g DB: :connect($dsn, $options); 
if (PEAR::isError($db)) ( 
die(C$db-sgetMessageO ) ; 


2005. augusztus 67 


0 Kiskapu Kft. Minden jog fenntartva 








0 Kiskapu Kft. Minden jog fenntartva 





Bizonyos esetekben néhány extra paraméter is belekerül 

a tömbbe, ilyen a fájl alapú SOLite adatbázis-kezelő, ahol 
a mode paraméterrel adható meg a fájl oktális jogosultsá- 

ga (például 644). Ezekről a DB csomag leírásában tájéko- 
zódhatunk. 


Második lépés: a lekérdezés indítása 

Ha ezzel megvolnánk, sikerült kapcsolatot teremteni 

a kiszolgálóval, jöhet az adatok lekérése. Ez alapesetben 
rendkívül egyszerű, a DB osztály gueryO) tagfüggvényé- 
nek segítségével paraméterként átadjuk az SOL lekérde- 
zést tartalmazó karakterláncot. Az eredményt egy DBresult 
típusú objektum képében kapjuk meg. 


include("DB.php"); 


$db - DB: :connect("mysgl : //rootalocalhost/test") ; 
$res - $db-sguery("select " from proba"); 


A dolog némiképp bonyolódik, ha szeretnénk paraméte- 
res lekérdezéseket készíteni. Ebben az esetben a lekérde- 
zési karakterláncban nem szerepelnek konkrét értékek, 
hanem azt a lekérdezőfüggvény egy másik paramétere- 
ként adjuk át. 


$res - 
—7m- ?" 
az § , 


$db-sguery( "select " from proba where ertek 
26); 


Ekkor a kérdőjel helyére a 26-os szám helyettesítődik be. 
Több paraméter esetén egy tömbként kell átadni az érté- 
keket, ahol a tömb elemei az egyes paramétereket jelentik 
sorrendben balról jobbra. 


$res - $db-sguery("select " from proba where kulcs 
57 7? and ertek - ?", array(13,26)); 


Harmadik lépés: az eredmények kezelése 

A lekérdezést legtöbb esetben azért adjuk ki, hogy feldol- 
gozzuk annak eredményét. Szó volt róla, hogy az ered- 
ményt egy DBresult típusú objektum képében kapjuk meg, 
amely magában hordozza a feldolgozáshoz, adatkinyerés- 
hez szükséges tagfüggvényeket. 

Menjünk végig egy eredményhalmazorn, és írassuk ki az 
egyes sorokat: 


include("DB.php") ; 

$db -— DB: : connect("mysgl : //rootalocalhost/test") ; 

$res - $db-sguery("select " from proba"); 

while ($res-sfetchInto($row, DB FETCHMODE.  ASSOC)) ( 
var. dump($row) ; 


; 


A fetchIntoO) metódus második paramétere azt határozza 
meg, hogy milyen formában adja vissza az adathalmaz kö- 
vetkező sorát. Alapértelmezetten a DB FETCHMODE, ORDERED 
konstans van érvényben, amely egy számokkal indexelt 
tömbben tartalmazza sorban az egyes mezők tartalmát. 

A kódrészletben is alkalmazott DB FETCHMODE. ASSOC 
asszociatív tömbbel tér vissza, ahol a kulcsok a mező 

nevei, az értékek a mező értékei. A harmadik lehetőség 
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a DB FETCHMODE, OBJECT konstans használata, amelynek 
hatására a visszatérési érték egy objektum lesz, ahol az osz- 
tályváltozók neve a mezőnevekkel egyezik meg, az értéke 
pedig a mezők tartalmával. 

Az eredményhalmazból egyéb értékes információ is kiderít- 
hető. A numRows O) metódus visszaadja, hogy hány sorral 
tért vissza a lekérdezés, a numcols() ehhez hasonlóan azt, 
hogy hány oszlopa van az eredményhalmaznak. Ezen kívül 
lekérdezhetjük az halmaz részletes felépítését 

a tableInfoO tagfüggvény segítségével, amely tartalmaz- 
za, hogy milyen oszlopai vannak az eredménynek, és azok 
milyen típusúak, milyen méretűek. 


Negyedik lépés: lekérdezés indítása előkészítéssel 
Számtalan esetben előállhat az a helyzet, hogy hasonló mó- 
dosító jellegű lekérdezéseket kell futtatnunk, ahol kizárólag 
a módosított értékek változnak, a lekérdezés többi része 
ugyanaz marad. Erre számtalan adatbázis-kezelő alkalmaz- 
za azt a megoldást, hogy paraméteres lekérdezéseket hasz- 
nálva első lépésben előkészíti, , lefordítja" a lekérdezést, 
majd ezt az előkészített parancsot tudjuk később, akár egy- 
más után sokszor lefuttatni. 

Például nézzük azt az esetet, amikor minden alkalmazott fi- 
zetését meg kell növelni egy előre meghatározott összeggel, 
amit a vezetőség állított elő személyre szólóan. Az SOL pa- 
rancs az alábbiak szerint néz ki: 


"update employees set salary-salary 4 ? where 
szdsz" 


A fentiekből már tudjuk, hogy a lekérdezés indítása során 
helyettesíthetjük be a ? jelek helyére a kívánt értékeket. 

A lekérdezést előkészítve, majd az előkészített parancsot 
mindig a megfelelő paraméterrel elindítva egyetlen fordí- 
tással megoldható a művelet. 

A PEAR DB biztosítja számunkra ezt a lehetőséget. A pél- 
dát lefordítva az alábbi kódrészletet kell végrehajtanunk: 


include("DB.php") ; 

$db -— DB: : connect(fmysgl : //root4álocalhost/test") ; 

$gry-" update employees set salary-salary 4 ? where 

Gijd z ?"; 

$sth-$db-:prepare($agry) ; 

foreach ($salary lift as $id-s$value) ( 
$db-sexecute($sth, array($id, $value)) ; 

3 


Jól látható, hogy egy referenciát kapunk vissza az előkészí- 
tett lekérdezésre, amelyet aztán ugyanúgy kell elindítani, 
mintha lekérdezés lenne, még a paramétereket is ugyanab- 
ban a tömbös formában kell átadni, ha több paramétert 
szeretnénk használni. Szót kell ejtenünk a lekérdezésben 
használatos helyfenntartókat (placeholder), ami az eddigi- 
ekben csak a ? jel volt. Ezeknek a helyére helyettesítődnek 
be a második paraméterként átadott változók. 

PEAR DB terminológiával a ? jel skalár értékek helyét jelöli. 
A behelyettesítés során automatikusan átalakítja a speciális 
karaktereket (escape), illetve ha karaktersorozatról van szó, 
aposztrofok közé teszi a DB a használt adabázis-kezelő 
elvárásainak megfelelően. 











A ! jel működése megegyezik az előzővel, azt leszámítva, 
hogy ott az értékek úgy helyettesítődnek be, ahogy átad- 
tuk, tehát nincs speciális karakterek átalakítása és 
aposztrofok közé tétel. 

Az utolsó az ét jel, amely egy valódi fájlnevet vár a behe- 
lyettesítési folyamat során. A behelyettesített érték ekkor 

a megadott fájl tartalma lesz. Ez olyan esetekben használ- 
ható jól, ahol fájlokat, vagy más bináris adatokat szeretnénk 
az adatbázisba tölteni. 

Felmerülhet sokunkban a kérdés a fenti példa alapján: ha 
egyszer úgyis tömbben vannak az adatok, és a megoldást 
pont arra találták ki, hogy ismétlődő szerkezetű adatokat 
minél gyorsabban lehessen adatbázisba tenni, akkor mi 

a fenének bejárni a tömböt, és egyenként betenni az értéke- 
ket? A válasz az, hogy nem kell, létezik erre is megoldás, 
amelyet az executemultipleO) tagfüggvény valósít meg. 


include("DB.php"); 

$db - DB: :connect("mysgl : //rootalocalhost/test") ; 
$gry-" update employees set salary-salary - ? where 
dei" e 

$sth-$db-sprepare($agry) ; 

$db-sexecute($sth, $salary lift); 


Az előkészítés-indítás jelleggel alkotott lekérdezést nem 
támogatja minden adatbázis-kezelő, de mi bárhol használ- 
hatjuk, mivel a DB alapértelmezetten emulálja ezeket 

a funkciókat számunkra (némi sebességcsökkenés árán 
természetesen). 


Otödik lépés: hibakezelés 

A PEAR statikus függvényt kínál az eredményhalmazok, 
adatbázis leírók ellenőrzésére. Ha valamely művelet során 
hiba történt, akkor az adott művelet visszatérési értéke egy 
DB. Error típusú objektum, amely ugyanazokat a tagfügg- 
vényeket kínálja, mint a PEAR Error osztály. Ha tehát hibát 
szeretnénk észlelni, akkor a hiba elkövetése után a művelet 
során keletkezett eredményhalmazt kell vizsgálat tárgyává 
tenni, mégpedig a PEAR (ill. DB Error) osztály statikus 
isErrorO tagfüggvényének segítségével. 


Kapcsolódási hiba észlelése 
$db - DB: :connect(fmysgl : //rootalocalhost/test") ; 
if (PEAR::isError($db)) ( 

die("Kapcsolódás sikertelen"); 


: 


Lekérdezés futtatási hiba észlelése 

include("DB.php") ; 

$db - DB: :connect("mysgl : //rootalocalhost/test") ; 

$gry-" update employees set salary-salary 4 ? where 

sre ete 

$sth-$db-sprepare($agry) ; 

$res-$db-sexecute($sth, $salary lift); 

if (PEAR::isError($res)) (í 
$res-sgetMessage0O ; //visszaadja 

//a hibaüzenete 

//visszaadja 

//a hibakódot 


$res-sgetCodeO ; 
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Mint látható, a DB. Error osztály is magában hordozza 
a hibakezelésre vonatkozó összes tagfüggvényt. 


A PEAR DB előnyei 


A fentiek alapján nem kell sokat ecsetelni a megoldás elő- 
nyeit: egyszerű, kis túlzással szabványos is, széles körben 
elterjedt, támogatott, dokumentált és nem nekünk kell 
megírni. Ez utóbbi két szempont igen jelentős: nem csak 

a kód megírására fordítandó időt takarítjuk meg, de a prog- 
ramhibák száma is minimális. Ezen túl már említettem, 
hogy ha más fejlesztő nyúl a kódhoz, nagy valószínűséggel 
ismerni fogja. Ha azonban ez nincs is így, a csomag igen 

jól dokumentált: nem csak API referencia áll rendelkezésre, 
de a PEAR honlapján részletes végfelhasználói dokumentá- 
ciót találunk szemléletes példákkal illusztrálva. 

A DB megoldásai rendkívül hasonlítanak például a JDBC 
filozófiához, ahol szintén minden adatbázist ugyanúgy 

kell kezelni: objektum-orientált és átgondoltságot sugároz, 
így nem csak PEAR DB fejlesztők tudják hatékonyan elsajá- 
títani a használat rejtelmeit, de olyanok is, akik JDBC adat- 
bázis absztrakciós rétegen nőttek fel. 


A PEAR DB hátrányai 


A modul rendkívül általános, számtalan dolgot tud, ennél- 
fogva igen valószínű, hogy számtalan szolgáltatását nem 
is fogjuk soha igénybe venni. Ezek csak ott vannak, lassít- 
ják a kódot, stb. Másfelől a valódi funkciók elrejtése (elő- 
készítéses lekérdezés nem támogatott adatbázison, ered- 
ményhalmazok burkolása, stb). jelentős többletterhelést 
okoz a programnak. Ez általában igaz minden emelt szin- 
tű felületre is. A dolog legteteje pedig az, hogy a kódunk 
hordozható marad az adatbázis-kiszolgáló fölött, annak 
típusától függetlenül. Az elején már említettem, hogy ezt 
a lehetőséget a legritkább esetben alkalmazzuk. Igaz, lehet 
a kompatibilitás mértékét szabályozni a kapcsolat felépíté- 
sekor, de még így is számtalan felesleges menet közbeni 
átalakítást cipel a hátán a rendszer. 

Mindezek ellenére személy szerint egyértelműen javaslom 
a használatát! A hétköznapi alkalmazások esetében soha 
nincs olyan teljesítményigény, amely kizárttá tenné a DB 
alkalmazásának lehetőségét, viszont szép, áttekinthető, 
átgondolt felépítésű kóddal büszkélkedhetünk. 

A DB csomagról igen részletes leírást talál az érdeklődő 
olvasó a http://www.pear.php.net/manual/en/ 
package.database.db.php címen. Ez a végfelhasználói 
dokumentáció sok-sok kódrészlettel. 

Aki ezzel nem elégszik meg, és ki akarja vesézni a teljes 
csomagot, annak ajánlom a http://www.pear.php.net/ 
package/DB/docs/latest/ címen elérhető API referencia 
leírást. Kevésbé érthető, mint az előző, viszont tényleg 
minden aprólékos információ megtalálható benne. 


Komáromi Zoltán 


A PEAR DB elérhetősége: 
5 http://wvww.pear.php.net/package/DB/ 
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Kávéfőzés lépésről lépésre (3. rész) 
Tömbök és interfészek, avagy a változatosság 


gyönyörködtet 


Az előző részben megismerkedtünk az öröklődés fogalmával. Ennek a módszer- 
nek a segítségével egy meglévő osztályt bővíthetünk újabb tulajdonságokkal és 
műveletekkel. Ehhez gondos tervezés esetén nincs szükség az ősosztály módosí- 
tására, valóban nincs másról szó, mint egyszerű kiterjesztésről. 


éldánkban egy állatokat jelképező osztályból 
E örököltettünk egy Tehen nevű osztályt, amely 

új tulajdonságát, a naponta termelt tej mennyisé- 
gét ki is tudta íratni a képernyőre. 
Ahhoz, hogy ennél a kiíratásnál megjelenítsük az állat 
hangját is, elveinknek ellentmondva módosítást hajtottunk 
végre az ősosztályban. Az Allat osztály hang változójának 
láthatóságát személyesről átállítottuk védettre. Erre nem 
lett volna szükség, ha tudjuk előre, hogy öröklődést szeret- 
nénk majd alkalmazni. Ez tehát elkerülhető egy átgondolt 
modell esetén, aminek megalkotásában nagy segítségünkre 
lehetnek az UML diagramok, melyek közül egyre szintén 
láttunk példát. 
Vessünk most egy pillantást az elmúlt alkalommal készített 
alkalmazás belépési pontjára: 


public static void main(String[] args) ( 


Tehen tehen - new Tehen("múúú", 20); 
Allat lo - new Allat("nyihaha"); 
Allat kutya - new Allat("vauvau"); 


tehen.szolaljMeg0) ; 

tehen.mennyiTejO ; 

1o.szolaljMegO ; 

kutya.szolaljMegO ; 
3 


Noha a forráskód az objektumközpontú filozófia számos 
ismertetőjegyét magán viseli, még mindig bőbeszédűnek 
érezhetjük a leírtakat. Felmerül a kérdés, hogy ha a tehen, 
a 1o és a kutya objektumot is megszólaltatjuk, miért kell ezt 
három, független metódushívással megtenni. Gondoljunk 
bele, ha nem csak három objektumunk lenne, hanem 
mondjuk száz. Ez esetben százszor kellene leírni gyakorlati- 
lag ugyanazt? Szerencsére nem. 

Mindhárom objektumban van valami közös, mégpedig az, 
hogy az Allat osztályból származnak. A 1o és a kutya köz- 
vetlenül, hiszen ezek az Allat példányai. A tehen ugyan 
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a Tehen osztály példánya, de ez az Allat kiterjesztése, 

így rá is igaz az állítás. Ez a közös vonás pedig egyszerűen 
megragadható úgy, hogy objektumainkat egy tömbbe 
gyűjtjük össze. 


Tömböm, tömböm mondd meg nékem 

Java-ban a tömb szerkezet is objektumként jelenik 
meg. Ez azt jelenti, hogy egy tömb létrehozásához 
ugyanúgy a new kulcsszót kell használnunk mint 
eddig. Fontos különbség viszont, hogy a referencia 
változónk, mellyel a létrejövő objektumra tudunk 
hivatkozni valamilyen tömb típusú, és ezért egyben 
indexelhető is. Lássuk, hogyan néz ki az átírt mainO 
függvény: 


public static void main(String[] args) ( 
Tehen tehen - new Tehen("múúú", 20); 
Allat lo - new Allat("nyihaha") ; 
Allat kutya - new Allat("vauvau") ; 


Allat[] allatok - new Allat[3]; 


allatok[0] - tehen; allatok[1] - lo; 
ss allatok[2] - kutya; 

for Cint i -— 0; i c allatok. length; 
51 44) ( 


allatok[i].szolaljMeg0O ; 
3 


tehen .mennyiTej 0) ; 
3 


A létrehozott objektumokból egy allatok nevű tömböt 
készítünk, amint az a metódus 4. és 5. sorában látható. 
Az allatok létrehozása után újabb példányosítás már 
nem történik, csupán feltöltjük a tömböt az objektumok 
referenciáival. Így az eredeti néven túl egy másik úton 








is megcímezhetjük ugyanazokat az objektumokat. 

Az - operátorral csupán az objektumok elérhetőségeit 
másoltuk át a tömbbe, nem a teljes objektumokat. 

Az ezután következő for ciklus C-ből ismerős lehet, viszont 
több ponton segít rajtunk a Java. A ciklus fejében három 
rész található, melyeket ; választ el egymástól. Az első rész 
készíti elő a használandó változókat, mivel ez még a törzs- 
be való első belépés előtt lefut. Kényelmes és hasznos, hogy 
a ciklusváltozót elég itt létrehozni, és nem kell a teljes függ- 
vény legelején. Ennek az a haszna is megvan, hogy a ciklus 
lefutását követően ez a segédváltozó megszűnik. A második 
rész a törzs minden lefutása előtt kiértékelődik, és csak 
akkor folytatódik a ciklus, ha ez a feltétel teljesül. Itt ellen- 
őrizzük, hogy a ciklusváltozó, amellyel a tömböt fogjuk in- 
dexelni, nem lépte-e túl a tömb méretét. Kihasználjuk, 
hogy a tömb egy objektum, és szerencsénkre a mérete 

egy tagváltozón keresztül lekérdezhető. Végül az utolsó 
rész az egyes lefutások után hajtódik végre, ezen a helyen 
növeljük a ciklusváltozót. 

Így a ciklus háromszor fut le, előbb a tehenet, majd a lovat, 
végül a kutyát szólaltatja meg. Ezzel a módszerrel elértük, 
hogy ha növelni szeretnénk az állataink számát, a kiíratás 
részébe már nem kellene belenyúlnunk. Tetszőleges számú 
referenciát tartalmazhat az allatok tömb, az összes hivat- 
kozott objektumnak meghívásra kerül a szolaljMegO 
metódusa. 

Jó kérdés, hogy ha ez ilyen remekül működik egy egysze- 
rű metódus meghívásakor, miért ne oldhatnánk meg ha- 
sonlóan az objektumok létrehozását. Ekkor nem is lenne 
szükség másra, csak a tömbre, melynek elemei egy hason- 
ló ciklusban egyenként kaphatnának egy új objektumot. 
Ennek jelen helyzetben több dolog is ellentmond. Egy- 
részt a tehén Tehen osztályból származik, és így noha hi- 
vatkozhatunk rá egy Allat típusú referenciával, de csak 
az Allat osztályban meglévő tagokat érhetjük el. Ha lét- 
rehoznánk egy Tehen típusú objektumot, de csak olyan 
referenciánk lenne rá, ami Allat típusú, elveszítenénk 
azt, amivel az ősosztályt kiegészítettük. Másrészt gond 
lenne a konstruktorok paraméterezésével is, hiszen hon- 
nan tudjuk egy ciklus belsejéből, hogy épp melyik hangot 
kell átadni. Ebben az esetben tehát ez nem egy jó ötlet, 
viszont több hasonló objektum létrehozásakor kényelmes 
megoldást jelenthet. 


Díjazzuk a teheneket 

Most játszunk el a gondolattal, hogy főnökünk hazaért az 
első vakációból és elmondja, milyen kiváló ötlete támadt, 
mialatt a Balaton partján pihent. Teheneink látható mó- 
don keményen dolgoznak, hiszen minden tehén objek- 
tumnak tulajdonsága a naponta termelt tej mennyisége. 
Jó lenne külön jutalommal díjazni ezt a megfeszített 
munkát. Ezért szükséges a jól dolgozó állatoknak egy 
jutalmazO metódus, mellyel kifejezhetjük elismerésün- 
ket a teljesítményért. 

Első ötletünk az lehetne, hogy egyszerűen vegyük fel 

a Tehen osztályban az említett eljárást, és mi is menjünk 
nyaralni. Emlékezzünk azonban vissza saját hibánkra, 
mikor egy egyszerű örököltetéshez bele kellett nyúlnunk 
az ősosztály kódjába. Ahhoz, hogy ne essünk újabb csap- 
dába, gondoljuk végig, mit állítanánk azzal, ha jelenlegi 
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modellünket úgy egészítenénk ki, hogy a Tehen osztályba 
minden további nélkül belevésnénk egy ilyen metódust. 
Ezzel azt fejeznénk ki, hogy a tehenek, és csak a tehenek 
jutalmazhatóak. Bármennyire is kedveljük ezeket a béke 
szimbólumaként ismert, szeretetreméltó állatokat, ezt nem 
jelenthetjük ki. 

Ha már az objektumközpontúság a magas fokú kód- 
újrahasznosítás kecsegtet, ne mondjunk ennek ellent 

egy helytelen modellel. A teheneket valóban meg lehet 
jutalmazni, ugyanakkor ez később igaz lehet a lovakra, 
vagy a kutyákra is, mi több, alkalmazásunk fejlődésével 
még emberekre is. Ezért az Allat osztály sem rendelkez- 
het egyértelműen a művelettel. Mit tehetünk ebben 

a helyzetben? 

Elsőként gondolhatunk arra, hogy készítünk egy Dolgozo 
osztályt, és ebből örököltetjük az állatokat, később az embe- 
reket jelképező osztályt is. Ez már egy fokkal jobb legelső 
megközelítésünknél, de még mindig nem helyes. Egy alkal- 
mazás osztályhierarchiája a valóság egy képe. Ha létrehoz- 
nánk egy ilyen nevű közös ősosztályt, az azt jelenthetné, 
hogy dolgozó az egész világ, és dolgozik benne minden 
állat és ember. Ne felejtsük el, egyelőre a lovak és a kutyák 
nem jutalmazhatóak! 

Érezzük, hogy az új metódus, ami keresztbe tett a nyarunk- 
nak, valamilyen formában önálló osztályként kell, hogy 
fellépjen. Kényelmes lenne, ha készíthetnénk egy Dolgozo 
osztályt, de ez nem közös ősosztály volna, hanem egy füg- 
getlen szerkezet. Ebből a szerkezetből lenne jó örököltetni 
azokat és csak azokat az osztályokat, amelyeknek jutalom 
szabható. Ez jelen esetben a Tehen osztályra lenne igaz, 
aminek viszont már van egy őse. 

Ha a C4-4 nyelv mellett döntöttünk volna a sorozat elején, 
ez nem lenne gond. Ott ugyanis megengedett a többszörös 
öröklődés. Java-ban ez már nem igaz, itt egy osztály köz- 
vetlenül csak egy ősből származhat. Ennek az az oka, hogy 
problémás annak a helyzetnek a kezelése, amikor egy tag 
két osztályban is szerepel, és ebből a kettőből örököltetünk. 
Azért, hogy ez még meggondolatlan tervezés eredmé- 
nyeként se fordulhasson elő, a Java nem támogatja 

a többszörös öröklődést. Amit e szándékosan kifelejtett 
módszer helyett használhatunk az az interfész. 


Interfészek, madárfiókák nélkül 

Az interfész hasonló a már megismert osztályokhoz, 
viszont nélkülözi a változtatható tulajdonságokat, azaz 

a nem állandó tagváltozókat, és a metódusok törzseit. 
Ezért tényleg nem más, mint az angol kifejezés, az 
interface magyar jelentése: felület. Egy interfész önmagá- 
ban nem használható, ha nem áll mögötte olyan osztály, 
amely megvalósítja. A megvalósítás azt jelenti, hogy az 
interfész által előírt összes metódus törzzsel együtt előfor- 
dul az adott osztályban. Lássuk, hogyan fest ez egy UML 
osztálydiagramon (1. ábra). 

Az ábrán is látható, hogy az interfész a gyakorlatban eléggé 
közel áll az osztályhoz. Egy hasonló felépítésű doboz jelké- 
pezi mindkettőt. Az interfésznek a fejléce azonban dőlt be- 
tűs, ami annak elvontabb, idegen kifejezéssel élve absztrakt 
voltát mutatja. Tagváltozói csak állandók lehetnek, jelen 
esetben ez a rekesz üres. Műveletei helyén most egyetlen 
metódus áll, ez a jutalmaz O. 


2005. augusztus n 


0 Kiskapu Kft. Minden jog fenntartva 








0 Kiskapu Kft. Minden jog fenntartva 

















A 


Dolgozo 


rjutalmaz(): void 








tej: int 


-tej: int 


-mennyiTej(): void 











T. ábra 


Az osztály és interfész közötti fogalmat akkor lehet jól meg- 
fogni, ha tisztán modellezési eszközként tekintünk rájuk. 
Egy osztály tulajdonságok és ezeken végezhető műveletek 
összessége. Az interfész ezzel szemben annak a leírása, 
hogy egy osztály milyen műveletekkel kell, hogy rendel- 
kezzen, ha ennek egy megvalósítása. Azt is fontos észreven- 
ni, hogy a megvalósítás jele az UML diagramon a szagga- 
tott nyíl, ami megkülönbözteti az örökléstől. Itt ugyanis 
nem meglévő tagok átvételéről, hanem adott fejlécű 
műveletek kialakításáról van szó. 

Ennek egy fontos következménye, hogy ha készítenénk 
Ember osztályt is, melynek példányait szeretnénk jutal- 
mazni, akkor ebben a jutalmaz metódust külön kell 
megvalósítani. Ez jól illeszkedik jelen modellünkbe, hiszen 
valószínűleg másképp szeretnénk jutalmazni egy embert, 
mint egy tehenet. Azokban az esetekben, ahol ez nem így 
van, át kell gondolni, hogyan lehetne megoldani a problé- 
mát tiszta öröklődéssel. 

Lássuk a Dolgozo interfész forráskódját. A már megszokott 
módon, Dolgozo. java néven kell elmenteni az alábbiakat: 


Jer 

$ Ez az interfesz egy olyan dolgozot 
ir le, amelyet meg lehet jutalmazni 
: A hogyan kerdese a megvalosito 

s osztaly feladata 


g 


x/ 
public interface Dolgozo ( 
/es 
" Megjutalmazza a dolgozot. 
47 
public void jutalmazO ; 
s 


A kód a megjegyzésekkel együtt is tömör és lényegre törő. 
Az interfész az azonos nevű kulcsszóval hozható létre. 

A metódusoknak csupán a fejlécét tartalmazhatja, melyet ; 
jellel kell lezárni. Nézzük most meg az új Tehen osztályt, 
amely már megvalósítja ezt az interfészt. 


Jer 
: Ez az osztaly egy tehenet ir le 
: Tulajdonsaga a tej mennyisege, amit egy nap ad. 
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s" Ezt ki lehet iratni a kepernyore. 

87 

public class Tehen extends Allat implements 
sDolgozo í 


e 
: A naponta adott tej mennyisege. 
9/ 


private int tej; 


e 
:" Letrehoz egy uj tehenet a megadott 
: hanggal, és napi tej mennyiseggel 


1/ 

public Tehen(String h, int t) ( 
super (h); 
tej -— t; 

1 

[7 


: Kiirja a kepernyore a napi 

: tej mennyiseget 

t/ 

public void mennyiTrejOŐ ( 
System.out.println(tej 4 " liter, 
54 hang); 


[7 

s A tehen megjutalmazasa 

s: eseten megszolal es elmosolyodik 
87 

public void jutalmazÓ 1 


System.out.println(hang 4 " :-)"); 


A változás mindössze az osztály fejlécének kiegészítését 
és az új metódus bevezetését jelenti. A fejlécben az 
implements kulcsszó mutatja a megvalósítást. Ennek 
megadásakor, ha elfelejtünk elkészíteni egy tagfüggvényt, 
az már fordításkor hibát okoz. Az új metódus a megjegyzés 
és az eddigiek alapján magától értetődő. 

Az elmondottak egy kicsit talán rávilágítanak annak 

a ténynek a miértjére, hogy egy jó programozó egy nap 
nem ír többet 20 sor kódnál. Rengeteg időt és fáradtságot 
takaríthatunk meg, ha a vad billentyűtépés helyett először 
belegondolunk abba, hogy mit szeretnénk elérni. Ezután 
érdemes elgondolkozni azon, hogy a fejünkben alakuló 
megoldás eléggé általános-e ahhoz, hogy joggal nevezhes- 
sük objektumközpontúnak. 

Miután felébredtünk a mély önelemzésből, térjünk 
vissza teheneinkhez. Mint azt már említettem, az egy 
osztályból származó egyedek közös vonását kihasználva 
egyszerű ciklusszerkezettel lépdelhetünk végig az 
objektumokon. Miért ne tehetnénk ezt meg az ugyanazt 
az interfészt megvalósító osztályok példányai esetében? 
Ennél mi sem egyszerűbb, amire jó példa az alábbi, 
újraírt mainO függvény: 











public static void main(String[] args) ( 
Tehen teheni - new Tehen("múúú", 20); 
Tehen tehen2 - new Tehen("múúú", 30); 
Allat lo - new Allat("nyihaha"); 
Allat kutya - new Allat("vauvau"); 


Allat[] allatok -— new Allat[4]; 
allatok[0] - tehenl; 

allatok[1] - tehen2; 

allatok[2] -— lo; 

allatok[3] - kutya; 


for Cint i - 0; i c allatok. length; 
51 44) í 
allatok[li].szolaljMegO ; 


Dolgozo[l] dolgozok - new Dolgozo[21]; 
dolgozok[0] - tehenl; 
dolgozok[1] - tehen2; 


for Cint i - 0; i c dolgozok. length; 
51 14) ( 
dolgozok[i].jutalmazO ; 


; 


Az alkalmazás fordítása és futtatása után a várt kimenetet 
láthatjuk: 


múúú 
múúú 
nyihaha 
vauvau 
múúú :-) 
múúú :-) 


Most csak két tehenünket illettük jutalommal, 

de a dicséretet osztó ciklus ennél sokkal többre képes. 
Ha a Dolgozo interfészt megvalósító osztályok tömbje, 
a dolgozok 1000 elemből állna, és akár az összes 
objektum más-más osztály példánya volna, akkor 

is működne az alkalmazás ennek a programrészletnek 
a módosítása nélkül. Az interfész ugyanis biztosítja azt 
az egységes felületet, hogy mindnek van jutalmazO 
metódusa. 


Egy hétköznapi példa 

Mivel elképzelhető, hogy az Olvasók egy része nem teljes 
munkaidőben foglalkozik lovakkal, kutyákkal, és tehe- 
nekkel, egy gondolatkísérlet erejéig próbáljunk meg egy, 
az üzleti életre végletekig kihegyezett világunkhoz köze- 
lebb álló problémát modellezni. Tegyük fel, hogy egy 
olyan alkalmazás készítése a célunk, amelyben egy cég 
munkavállalóit kell kezelni. Erre a jelen cikksorozaton 
edzett programozó azonnal rávágja, hogy természetesen 
minden alkalmazott önálló objektum kell, hogy legyen. 
Ez egy jó megközelítés, hiszen minden dolgozónak van 
neve, életkora, munkaköre, fizetése, amik tekinthetők az 
objektum tulajdonságainak. Emellett minden dolgozónak 
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lehet feladatot kiadni, szabadságra küldeni, illetve cé- 
günk humán erőforrás politikájától függően bért emelni, 
illetve csökkenteni. Ezek pedig az objektumon végezhető 
műveletek. 

Eldöntöttük tehát, hogy mi fog objektumnak számítani. 
Noha a válasz itt kézenfekvő volt, a tervezésnek ez a lépése 
nem mindig ilyen könnyű, ezért mindig éljünk a legna- 
gyobb alkotói szabadsággal, és gondoljuk meg, mit nyerhet- 
nénk, ha másképp fogalmaznánk meg a modellt. Adott 
esetben elképzelhető, hogy az egyes feladatköröket érde- 
mes objektumoknak tekinteni. Most azonban maradjunk 
az egy dolgozó - egy objektum meggondolásnál, ami a va- 
lóságnak is egy jó képe. Miután az objektumok osztályok 
példányai, meg kell fontolni, hogy milyen osztályhierarchi- 
át szeretnénk kialakítani. Elérkeztünk az első buktatóhoz. 
Elsőre eszünkbe juthat, hogy van a vállalatnak egy belső 
struktúrája, ahogy a dolgozók egymás fölé vannak ren- 
delve, használjuk ezt osztályhierarchiának. Az objektum- 
központúság tényleg egyfajta leírása a világnak, amiben 
élünk, de nem szabad az életben használt modelleket 
gondolkodás nélkül ráerőltetni alkalmazásainkra. 

Több, mint valószínű, hogy alkalmazásunkban egy főnök 
objektumon többféle műveletet végezhetünk, mint egy 
egyszerű dolgozón. Visszatérve a humán erőforrás politi- 
kához, lehet, hogy fizetést csak a főnök objektumok ese- 
tén lehet emelni. Ebben az esetben hibás lenne a vállalat 
hierarchiáját átvenni, hiszen ha a dolgozó kiterjeszti 

a főnököt, akkor neki is önműködően meglesz az összes 
metódus az ősosztályból. 

A legelső megoldási kísérlet kudarca ellenére érezhetjük, 
hogy nem járunk messze az igazságtól. Van valami köze 

a kettőnek egymáshoz, csak nem ugyanazok. Gondoljuk 
meg, hogy egy vállalat szervezeti felépítésének diagramm- 
ján a felelősség lentről felfelé nő, a lehetőségek is ebben az 
irányban szélesednek. Egy UML diagramon az ősosztály 
jellemzően az öröklő osztály felett áll, ami pont fordított 
irányt mutat az előzőhöz képest. Egy, a Balaton partjáról 
érkező szellő azt súgja, hogy fordítsuk meg a szervezeti 
felépítés diagrammját, és így fejjel lefelé nézve pont 
megadja a megoldást. 

Így azonban többszörös öröklődésbe futunk, ami, mint 
tudjuk nem megengedett Java-ban. A megközelítés tehát jó, 
csak meg kell fontolnunk, mit tehetünk meg interfésznek, 
és mit valódi osztálynak. A sorozatban most először egy 
próba erejéig megteszem ezt házi feladatnak. A probléma 
nem túl konkrét, így ki-ki saját ízléséhez mérten bonyolít- 
hatja. E-mailben várom tehát a különféle dolgozók fize- 
tésének, korának, szabadsága időpontjának kiíratását. 

Ha a kedves olvasó elakadt valahol, akkor is írjon bátran, 
szívesen segítek. 

Ha már ennyire szép formájú megjegyzéseket készítettünk 
eddig, következő hónapban kipróbáljuk a javadoc-ot, 

és próbára tesszük a Java kivételkezelését is. 
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- Fülöp Balázs (bigwig42Ogmail.com) 

21 éves, imádja a Túró Rudit, a Debian Linuxot 
és a teheneket. Kedvenc írója Slawomir Mrozek. 
Leginkább a számítógépes hálózatok biztonsága 
érdekli. A BME VIK műszaki informatikus 

szak hallgatója. 
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Hálózatok (20. rész) 


ARP., RARP, BOOTP DHCP CDIR 


Folytatjuk tovább az internet vezérlő protokolljainak ismertetését, majd rátérünk 
az IP protokoll egyre égetőbb problémájára: a még szabadon kiosztható IP címek 


vészes fogyására. 


orozatunk előző részében megismerkedtünk az 
S IP címekkel, amelyek lehetővé teszik a gépek 

egyértelmű azonosítását az interneten. Felmerül 
azonban egy probléma: a gépek hálózati csatolói mit sem 
tudnak ezekről a címekről, ők ugyanis egy alacsonyabb 
szinten, az adatkapcsolati rétegben működnek. 
Emlékezzünk vissza, hogy az adatkapcsolati réteg felelős 
azért, hogy egy LAN-on belül az állomások üzeneteket küld- 
hessenek egymásnak keretek formájában. Mivel a kommuni- 
káció nyílt csatornán zajlik, ezért az összes gép megkapja az 
összes keretet, majd ebből kell kiválogatniuk azokat, amelyek 
nekik szólnak. Így minden keret esetében meg kellett 
mondanunk a célpont hálózati csatolójának MAC címét. 
Ez például az Ethernet esetében egy 48 bites azonosító, amely 
a világ összes Ethernet hálózati kártyájában különböző. 
Amikor az útválasztó az alhálózattól megkap egy olyan cso- 
magot, amely egy, a saját hálózatán belüli géphez tart, akkor 
a kérdéses csomagot ki kell ,bontania", majd annak tartalmát 
az adatkapcsolati réteg segítségével keretek formájában eljut- 
tatnia a címzetthez. Az adatkapcsolati réteg azonban egy 
MAC címet vár, a beérkezett csomag fejléce azonban IP címet 
tartalmaz. Az útválasztónak tehát ki kell derítenie az adott 
IP címhez tartozó hálózati csatoló MAC címét. Ehhez a leg- 
egyszerűbb módszer az, ha az útválasztó , bekiabál" a LAN 
csatornájába, hogy az adott IP cím gazdája jelentkezzen. 
Erre szolgál az ARP nevű protokoll. 


ARP (Address Resolution Protocol) 

Az ARP protokoll tehát az IP címek MAC címekre történő 
leképezésére szolgál. Működése nem túl bonyolult. Ha egy 
gép érdeklődni szeretne például a 213.178.107.36 IP címhez 
tartozó MAC cím iránt, akkor csak küld egy adatszórásos 
üzenetet, amelyben megkérdezi: , Kié a 213.178.107.36 IP 
cím?" . Erre az üzenetre minden gép reagálni fog, és össze- 
hasonlítja saját IP címét a kérdésben szereplővel. Amelyik 
gép IP címe egyezik, az visszaküld egy válaszüzenetet, 
amelyből a kérdező megtudja a keresett gép MAC címét. 
Ahhoz azonban, hogy az ARP igazán hatékony legyen, 
szükség van némi optimalizálásra. Beláthatjuk, hogy nem 
igazán járható az az út, ha minden egyes beérkező csomag 
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esetén újra és újra érdeklődünk a MAC cím iránt. Mivel 

a gépek IP címei és hálózati csatolói nem változnak túl 
nagy gyakorisággal, ezért a birtokunkba került MAC címe- 
ket egy darabig eltárolhatjuk a memóriában. Persze ha 
mégis bekövetkezik valami változás, akkor arra gyorsan 
kell reagálnunk, így a gyorsítótárban tárolt információk 
érvényességének pár percen belül le kell járniuk. 

A hatékonyságot tovább növelhetjük azzal, ha egy MAC 
cím után érdeklődő gép az ARP keretben a saját IP címét 
is elhelyezi. Ezt a címet pedig a LAN összes gépe eltárolhat- 
ja a gyorsítótárában, így az ARP keretet küldő gép IP címe 
már mindenki számára ismerté válik. 

Amikor egy gép elindul, mindig küld egy ARP keretet, 
amelyben a saját IP címéhez keresi az ahhoz tartozó MAC 
címet. Ezzel egyrészt a LAN gépei tudomást szereznek az 
újonnan elindult gép IP címéről, másrészt így elkerülhető 
az IP cím ütközés. Ha ugyanis válasz érkezne a gép által 
küldött ARP keretre, akkor az azt jelentené, hogy a hálóza- 
ton valaki más is rendelkezik ugyanazzal az IP címmel. 
Ilyen esetben a gépnek nem szabad elindulnia. 

Mi a helyzet azonban akkor, ha a keresett gép egy másik 
LAN-on található? Tegyük fel, hogy van egy B osztályú 
címtartományunk (például a 172.16.x.x), és a gépeinket két 
különálló LAN-ba szervezzük. A két hálózatot egy útválasz- 
tó köti össze, amelynek két IP címe van, tehát mindkét 
LAN-nak tagja. 

Tegyük fel, hogy az A gép üzenetet szeretne küldeni 

a C gép számára, ám nem ismeri annak MAC címét, ezért 
egy ARP keretet bocsát a hálózatra. Ezt a keretet azonban 
a C gép sosem fogja megkapri, mivel az útválasztó nem 
továbbítja az adatkapcsolati réteg adatszórásos kereteit. 
Erre a problémára két megoldás is létezik. Az első az, hogy 
az útválasztó válaszol azokra az ARP kérésekre, amelyek 
egy másik hálózatbeli gép iránt érdeklődnek. Ha tehát az 
A gép érdeklődik a C gép MAC címe iránt, akkor ennek 
hatására az útválasztó elküldi A-nak a saját MAC címét, 
így az A minden C-nek szóló keretét az útválasztóhoz 
továbbítja. Az útválasztó ezután gondoskodik arról, hogy 
ezek a keretek eljuthassanak C-hez. Ezt a technikát nevez- 
zük helyettesítő ARP-nak (proxy ARDP). 








Ez a megoldás feltételezi azt, hogy az útválasztó pontosan 
tudja, mely alhálózatokat szolgálja ki. A másik megoldás 
szerint ezt a ,tudást" inkább a gépekre kéne bízni, azaz fel 
kell ismerniük, hogy a keresett gép egy másik hálózatban 
van. Ebben az esetben az összes forgalmat egyből az útvá- 
lasztó felé irányítja. 


RARP, BOOTP, DHCP 

Láttuk, hogyan tudjuk az IP címeket leképezni MAC 
címekre. Időnként azonban ezt fordítva is meg szeretnénk 
tenni: egy ismert MAC címhez keressük a hozzá tartozó 

IP címet. 

Erre a legjobb példa az, amikor egy olyan munkaállomást 
indítunk, amely nem rendelkezik háttértárolóval, így magát 
az operációs rendszert is a hálózatról tölti be. Amikor a gép 
elindul, akkor fel kell vennie a kapcsolatot a fájlszerverrel, 
ahonnan letölti az operációs rendszert tartalmazó képfájlt. 
Ehhez azonban a gépnek meg kell tudnia az IP címét. 

Erre szolgál a RARP (Reverse Address Resolution Protocol), 
amely tulajdonképpen az ARP fordítottja, csak itt a MAC 
címet adja meg, és az ahhoz tartozó IP címre kíváncsi. 
Amikor a RARP szervert futtató gép meglátja ezt a kérést, 
akkor egy táblázatból kikeresi, mi az adott géphez rendelt 
IP cím, majd azt visszaküldi. 

A RARP-nál is felmerül az a probléma, hogy az útválasztók 
nem továbbítják az adatkapcsolati réteg szintű adatszórá- 
sos forgalmat, tehát minden LAN-nak rendelkeznie kéne 
saját RARP szerverrel. E probléma megoldására jött létre 

a BOOTP (Bootstrap Protocol), amely adatkapcsolati réteg 
szintű keretek helyett IIDP csomagokat használ. 

A BOOTP működése nagyon egyszerű. Amikor a gép 
elindul, a 255.255.255.255-es IP címre (amely az adatszó- 
rásra fenntartott speciális IP cím) egy UDP csomagot, 
úgynevezett BOOTREGUEST csomagot küld, amely 
tartalmazza a gép MAC címét. Ezután vár a válaszra, 

ha az nem érkezik meg egy bizonyos időn belül, megis- 
métli a BOOTREOUEST csomagot. 

A BOOTP kiszolgáló a BOOTREOUEST-re válaszul egy 
úgynevezett BOOTREPLY csomagot küld, amely tartalmaz- 
za a gép IP címét, a képfájlt tároló fájlszerver címét, vala- 
mint az alapértelmezett átjárót és az alhálózati maszkot. 
Ezután a gép kapcsolatba lép a fájlszerverrel, és például 

a TFITP (Trivial File Transfer Protocol) protokoll segítségével 
letölti az operációs rendszert tartalmazó képfájlt. 
Manapság azonban már szinte az összes számítógép ren- 
delkezik háttértárral, így önállóan is képes betölteni az ope- 
rációs rendszerét, csak a hálózati beállításokat kell , letölte- 
nie". Ezért a BOOTP-t továbbfejlesztették úgy, hogy az al- 
kalmasabb legyen az olyan számítógépek konfigurálására, 
amelyeket gyakran hordoznak hálózatok között (például 
laptopok), ezzel megkönnyítve a felhasználók és a rend- 
szergazdák életét. Erre szolgál a DHCP (Dynamic Host 
Configuration Protocol). 

A DHCP ugyan felülről kompatibilis a BOOTP-vel, mégis 
számos dologban különbözik tőle. Ezek közül a legfonto- 
sabb az, hogy a BOOTP esetében a gépekhez történő IP 
címhozzárendelés általában statikusan történik, azaz egy 
adatbázisban előre meghatározzuk, hogy melyik gép melyik 
IP címet kaphatja meg. A DHCP esetében a címkiosztás álta- 
lában dinamikus, tehát legtöbbször csak egy halmazt defini- 
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álunk, amelyből kiosztjuk a címeket a gépek számára. Egy 
állomás bekötése egy DHCP-t használó hálózatba igazából 
nem több, mint a hálózati kábelt a géphez csatlakoztatni. 


Többesküldés (multicastiny) 

Bizonyos alkalmazásoknak szüksége lehet arra, hogy egy 
csomagot egyszerre több címzetthez is eljuttathasson. Ilyen 
például egy videokonferenciát megvalósító program. Az 
adatszórás, mint megoldás, természetesen szóba sem jöhet, 
hiszen a csomagok olyan gépekhez is eljutnának, akik nem 
is érintettek akommunikációban (nem beszélve arról, hogy 
az útválasztók általában nem továbbítják az adatszórásos 
csomagokat). Az unicast, azaz amikor a csomagot egyesével 
elküldjük az összes címzetthez sem bizonyul mindig haté- 
konynak. Tegyük fel, hogy a videokonferencia két résztve- 
vője ugyanabban a távoli hálózatban van. Az unicast hasz- 
nálatával két ugyanolyan csomagot küldünk a hálózat felé, 
ami erőforrás-pazarló. Sokkal hatékonyabb lenne, ha csak 
egy csomagot küldenénk, amit a kommunikációban részt- 
vevő mindkét fél megkapna. 

Erre jelent megoldást a többesküldés (multicasting) , amely 
lehetővé teszi, hogy egy csomagnak több címzettje is lehes- 
sen. A többesküldésről technikájáról már ejtettünk pár szót 
a hálózati réteg elméleti tárgyalásakor. Most azt tekintjük át, 
miként is működik ez az Internet esetében. 

A többesküldés megvalósításának első kérdése az, hogy mi- 
ként lehet összehozni azt az IP protokollal. Erre szolgálnak 
a speciális D osztályú IP címek (224.0.0.0 — 293.255.255.255). 
Minden, ebbe a csoportba tartozó IP cím egy többesküldési- 
csoportot határoz meg, így a kommunikációban résztvevő 
gépek külön IP címmel rendelkezhetnek. Könnyen kiszá- 
molható, hogy egyszerre 250 millió csoport létezhet, amely 
az internet mai méretét tekintve (lásd később) nem tűnik 
túl soknak, minden estre ma még elégnek bizonyul. 

A többesküldési-csoportoknak két fajtája van: az állandó és 
az ideiglenes. Az állandó csoportok olyanok, amelyek folya- 
matosan léteznek. Ilyen például a 224.0.0.1, amely a LAN- 
on belüli összes gépet tartalmazza. Szintén állandó csoport 
a 224.0.0.2, amelynek a LAN-on lévő útválasztók a tagjai. 
Az ideiglenes csoportok viszont nem léteznek állandóan, 
ezeket használat előtt mindig létre kell hozni. A csoportok- 
hoz a gépek szabadon csatlakozhatnak, illetve kiléphetnek 
onnan. Egy csoport akkor szűnik meg, amikor már egy gép 
sem csatlakozik hozzá. 

A többesküldést speciális útválasztók valósítják meg, ame- 
lyek gyakran egybe vannak építve a ,közönséges" útválasz- 
tókkal. Ezek bizonyos időközönként megkérdezik a hozzá- 
juk kapcsolódó hálózat gépeit (általában többesküldéssel, 

a 224.0.0.1-es címen keresztül), hogy mely többesküldési 
csoportoknak a tagjai. Ezt az úgynevezett IGMP (Internet 
Group Management Protocol — internet csoportfelügyeleti 
protokoll) segítségével végzik, amely az ICMP-hez nagyon 
hasonló vezérlőprotokoll. A többesküldéses útválasztók fe- 
szítőfák felállításával jelölik ki a többesküldéses csomagok 
útvonalát (lásd sorozatunk 17. részét). 


CIDR (Classless InterDomain Routiny) 

Az IP jelenlegi verziója (az IPv4) jól bevált, kiforrott 
protokoll, bizonyítékul szolgál erre az Internet hihetetlen 
méretű terjedése. Ironikus módon a hálózat nagyléptékű 
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növekedése fogja az IPv4 vesztét is okozni: a szabad 
(még ki nem osztott) IP címek száma vészesen csökken. 
Pontosabban nem is a szabad IP címek fogynak, hiszen 
abból több mint 4 milliárd létezik. A gond a címek tarto- 
mányokra való tagolásából adódik. Mint utóbb kiderült, 
elég szerencsétlen módon sikerült az osztályokat megvá- 
lasztani: az A osztályú tartományok a legtöbb hálózat 
számára túl nagy, a C osztályúak pedig túl kicsik. Sok 
intézmény tehát érthető módon B osztályú tartományo- 
kért folyamodott. Egy felmérésből azonban kiderült, 
hogy a B osztályt birtokló hálózatok jelentős része nem 

is használja ki igazán címtartományát, akár egy C osztá- 
lyú címcsoporttal is vígan működhetne. Az üzemeltetők 
mégis egy B csoportot kérvényeztek, hiszen így nem 
okoz majd kellemetlenséget, ha a gépek száma egyszer 
majd 254 fölé emelkedik. Így azonban IP címek milliói 
mennek veszendőbe. 

Ez a probléma valószínűleg elkerülhető lett volna azzal, 

ha a C osztályú címeknél 8 helyett 10 bitet szánunk a gépek 
azonosítására. Ez már elegendő lett volna a hálózatok több- 
ségének, így tényleg csak az folyamodott volna B osztályú 
tartományért, akinek tényleg szüksége is lett volna rá. 

A most használt címtartományok másik problémája az 
útválasztók táblázatainak növekedésében jelentkezik. 

Az útválasztók számára az IP címek két részből állnak: 

a számukra teljesen érdektelen gépcímből, és a hálózat- 
címből. Az útválasztóknak minden hálózatcímhez fenn 
kell tartaniuk egy bejegyzést a forgalomirányító táblázatuk- 
ban, amely megadja, hogy melyik kimeneten kell az arrafe- 
lé tartó csomagot továbbítani. 

Ahogy egyre gyarapszik az Internethez kapcsolt hálózatok 
száma, úgy nőnek az útválasztók táblázatai. A nagyméretű 
táblázatokkal azonban máshogy kell bánni. Egyrészt több 
memória is kell hozzá, másrészt komplexebb kereső algorit- 
musok, amelyek segítségével az útválasztók gyorsabban 
megtalálhatják a kívánt bejegyzést. Sok, régebbi útválasztó 
által használt eljárás elavul, így azok az útválasztók nem 
tudják hatékonyan ellátni feladatukat. 

A nagy méretű táblázatokkal azonban más baj is van. 

Az útválasztóknak folyamatosan cserélgetniük kell egymás 
között a táblázatuk tartalmait. Kis méretű táblázatok eseté- 
ben ez könnyen ment, nagy méret esetében azonban a fo- 
lyamat egyrészt lassú, másrészt sérülékeny. Egy nagyobb 
adatmennyiség nagyobb valószínűséggel sérül meg egy 
átvitel alatt. A sérült táblázatok pedig sok galibát okozhat- 
nak a forgalomirányításban. 

A forgalomirányító táblázatok azért nőnek ilyen mérték- 
ben, mert az IP címek nem tartalmaznak semmiféle in- 
formációt arra nézve, hogy az adott hálózat merre talál- 
ható (nem tükrözik az Internet topológiáját). Ha például 
kiköthetnénk azt, hogy az IP címek első három bitje 

a földrészt, a következő öt pedig az országot jelölje, ahol 
az adott hálózat található, akkor a forgalomirányító táb- 
lázatban jelentős számú bejegyzést megspórolhatnánk. 
Sajnos erre a rendelkezésre álló 32 bit már kevés, nem 

is beszélve arról, hogy ez a megoldás nem használná ki 
hatékonyan a címeket, hiszen a kisebb országok is ugyan- 
annyi címet kapnának, mint a nagyobbak. 

Sajnos erre a két problémára nem létezik igazi megoldás (il- 
letve létezik: az egész IPv4 lecserélése egy újabb verzióra). 
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Csupán annyit lehet tenni, hogy bizonyos intézkedésekkel 
időt nyerünk, de előbb vagy utóbb ismét szembekerülünk 
ezekkel a gondokkal. 

Az egyik ilyen intézkedés, amely segítségével elódázható 
az Internet problémáinak megoldását a CIDR (Classless 
InterDomain Routing - osztály nélküli tartományok közöt- 
ti forgalomirányítás), amely ,megreformálja" a C osztályú 
IP címtartományok kiosztását. Először is, akinek nincs 
szüksége egy teljes B osztályú tartományra, mert például 
csak 400 gépet szeretne az Internethez kapcsolni, akkor 
az kap egy 512 darab címből álló egybefüggő címblokkot 
(két összefüggő C osztályú címtartományt). Akinek több 
gépe van, például 2000, az nyolc darab C osztályú tarto- 
mányt kap. 

A kiosztásnál azonban azt is figyelembe veszik, hogy az 
adott hálózat a világ melyik pontján található. Ha például 
Európában, akkor a címeket a 194.0.0.0 — 195.255.255.255-ig 
terjedő tartományból osztják ki. Ezzel csökkenthetjük a for- 
galomirányító táblázatok méreteit, hiszen ha az útválasztó 
egy ilyen címmel találkozik, akkor egyből az alapértelme- 
zett európai átjáróhoz küldheti. 

Persze az európai útválasztóknak részletes ismeretekkel kell 
rendelkezniük az európai hálózatokról. Felmerül a kérdés, 
hogy mivel felrúgtuk az eddig használt IP címosztályokat, 
az útválasztók miként döntik el egy csomagról, hogy azt 
mely hálózat útválasztójához kell továbbítania? Továbbá 
nem áll-e fent megint a forgalomirányító táblázatok méreté- 
nek megugrásának veszélye? 

Az utóbbi kérdésre a válasz az, hogy nem tartunk 

fent minden C osztályú IP címnek külön bejegyzést, 
hiszen a CIDR használatával örökre búcsút mondnunk 
az IP címek ily módon történő felosztásának. Most 

már mi határozzuk meg, hogy az IP címből hány bit 
szolgáljon a hálózat azonosítására. A forgalomirányító 
táblázatban csak a kiosztott címcsoport alapcímét és 
annak 32 bites maszkját tároljuk el. (Például egy intéz- 
mény igényt tart 2048 darab IP címre, így megkapja 

a 192.24.0.0 — 194.24.7.255-ig tartó címeket. A maszk 

azt mondja meg, hogy hány bit szolgál a hálózat azo- 
nosítására. Jelen esetben 21 darab bit, így a maszk 21 
darab egyesből, és 11 darab 0-ból fog állni. Egy hálózat 
alapcímén a kiosztott címcsoport első címét értjük, jelen 
esetben ez a 192.24.0.0). 

Tegyük fel, hogy beérkezik egy olyan csomag, amely 

a 192.24.2.5-ös IP címre tart. Ilyenkor az útválasztónak 
végig kell néznie a forgalomirányító táblája összes bejegy- 
zését, és mindegyiken el kell végeznie a maszkolást, azaz 
egy logikai ÉS műveletet a csomag célpont címe és az 

adott bejegyzés maszkja között. Ha az így kapott érték 
megegyezik az adott hálózat alapcímével, akkor megtalál- 
tuk azt a hálózatot, ahova a csomag tart, így továbbíthatjuk 
a megfelelő útválasztó felé. 

A következő részben megismerkedünk az IP protokoll 

új generációjával, az IPv6-al, amely 32 bit helyett 16 báj- 
ton tárolja a címeket, kiküszöböli az IPv4 hibáinak 

nagy részét, és mindezek mellett sokkal hatékonyabb 

és rugalmasabb is nála. 


Garzó András 
garzo(vinterware.hu 











Elfeledett terminálok 


A parancssor megszállottai grafikus játékszereket kapnak, melyekkel 
helyet takaríthatnak meg, háttereket használhatnak vagy akár több 
terminált is elindíthatnak egyetlen paranccsal. 


érlek, Francois, ne sírj. Mi bánt ennyire? Az ét- 
AA terem fantasztikusan néz ki, mon ami. Minden 
készen áll. Ugyan mi lehet ilyen rossz? Owoi? 
Átfutottad a menüt, és láttad, hogy terminálprogramok 
szerepelnek rajta, ez hangolt le ennyire? Ó, Mon Dieu, 
Francois, a terminálok nem valakinek vagy valaminek 
a végét jelentik, hanem a héjhoz tartozó ablakokat, 
mint a GNOME terminál, az xterm vagy a KDE Konsole. 
Érkezőben a vendégeink, Francois. Üdvözlök mindenkit 
a Chez Marcel-ben, ahol a finom linuxos fogások mellé kivá- 
ló borok társulnak. Foglaljatok helyet, helyezzétek magatok 
kényelembe. Francois, kérlek menj le a pincébe, és hozd fel 
az 1999-es Cőte du Rhőne-t. Vite! 
Mai menünk a rendszerfelügyeletről szól, és bizony nem 
kis gondot okozott az összeállítása, hiszen ezt a témát 
számtalan szemszögből lehet megközelíteni. Aztán feltet- 
tem magamnak a kérdést: melyik az az eszköz, amit a rend- 
szergazdák a legtöbbet használnak? A válasz kézenfekvő 
volt, a parancshéjat, amely valamilyen terminálemulátor- 
ban fut. Bár ma már alapvető eszköznek számítanak, 
a terminálprogramok komoly fejlődésen mentek keresztül 
a jó öreg xterm ideje óta. 
Akik még túl fiatalok ahhoz, hogy emlékezhessenek rá, 
azoknak elmondanám, hogy azért hívjuk őket terminál- 
programoknak vagy -emulátoroknak, és nem héjablakok- 
nak, mert eredetileg azoknak a termináloknak a szoftveres, 
asztali gépekre készült megfelelői voltak, amelyeket régen 
fizikailag csatlakoztattak a nagygépekhez. Na, míg én me- 
sélek, Francois meg is érkezett a borral. 
Az évek során jó néhány terminálprogramot használtam. 
Eredetileg csak a sima xterm volt, ami a legtöbb linuxos 
rendszeren ma is megtalálható. Ha ki akartuk csicsázni, 
megváltoztattuk a betűtípus vagy a háttér színét, de másra 
nem nagyon adott lehetőséget. Ha például az xtermet acél- 
kék háttérrel és piros betűtípussal akarjuk futtatni, a követ- 
kező parancsot kell kiadnunk: 


xterm -background "SteelBlue" -foreground "Red" 
Később felfedeztem egy másik, rxvt nevű programot, 


a legtöbb rendszeren ez is megtalálható. Ez már kicsi- 
vel több beállítási lehetőséget kínált. Nemcsak jobban 
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1. ábra Átlátszóság, hátterek, témák és egyebek Eterm alatt 


nézett ki, mint az xterm, de XPM bittérképet is képes 
volt háttérként használni, ami abban az időben egész 
jó dolog volt: 


rxvt -pixmap 
/usr/share/themes/BrushedMetal/gtk/bg.xpm -fg 
black 


Később jött az első olyan terminálemulátor, amit igazán 
szeretni tudtam, és amit ma is örömmel használok. A neve 
Eterm, és bár az xterm helyettesítőjének tervezték az 
Enlightenment ablakkezelőhöz, GNOME, XFCE, KDE vagy 
bármi más alatt is működnie kell. Érdemes szétnézni ter- 
jesztésünk CD-lemezén, mert alapesetben valószínűleg nem 
települ. Az Eterm legújabb változatát az Eterm webhelyről 
is beszerezhetjük (lásd az internetes forrásokat). 

Az Eterm nemcsak jól néz ki, de tud néhány nagyszerű 
dolgot is. Például sokféle háttérkép kezelésére képes -— sőt, 
eredetileg is jó néhány tartozik hozzá, ezek egy része csem- 
peszerűen tölti ki a hátteret, mások teljes méretűek. Ha 
ilyet szeretnénk látni a képernyőnkön, csak kattintsunk 

az Eterm menüsorának Background (Háttér) majd Pixmap 
(Bittérkép) elemére, majd válasszunk ki egyet a rendelkezé- 
sünkre álló képek közül. 

Ugyancsak módosíthatjuk a betűtípus méretét, a fényerőt, 
a képélességet, a gördítősáv stílusát és sok egyebet. 

Ha kívánjuk, saját, testreszabott menüt is létrehozhatunk. 
Ha elégedettek vagyunk a módosított beállításokkal, 
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kattintsunk a menüsor Eterm, majd Save 
User Settings (Felhasználói beállítások 
mentése) elemére. 

Az Eterm témákkal is felöltöztethető. 
Kattintsunk az Eterm webhelyén találha- 
tó Themes (Témák) hivatkozásra, és 
számtalan téma tárul elénk. A tetszésün- 
ket elnyerőket .tar és .gz csomagok for- 
májában szabadon letölthetjük és telepít- 
hetjük. Telepítésükhöz hozzunk létre 
egy .Eterm könyvtárat a $HOME könyvtá- 
runkban, majd ez alatt egy themes 
könyvtárat. Az egyes témákat elég ki- 
bontanunk ide, máris elérhetőkké vál- 
nak. Ha az Etermet a következő alkalom- 
mal már a kiválasztott témával akarjunk 
indítani, akkor a következő parancsot 
kell kiadnunk: 
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Eterm -t téma neve 


Én a legjobban mégis azt szeretem az 
Etermben, hogy átlátszóvá lehet tenni. 
Különösen azért tetszik ez a szolgáltatás, 
mert így figyelemmel kísérhetem a hát- 
térben gördülő rendszernaplókat, és per- 
sze a kedvenc háttérképem is látható 
marad. Ehhez csak annyit kell tennünk, 
hogy rákattintunk a menüsor 
Background (Háttér) elemére, majd enge- 
délyezzük a Toggle Transparency (Átlát- 
szóság átkapcsolása) beállítást. A kapcso- 
ló KDE alatt nem működik, de GNOME, 
WindowMaker és egyebek alatt igen. 

Ha például az Apache naplóit akarom 
figyelni a webkiszolgálómon, és átlátszó 
Etermet akarok futtatni, a következő 
parancsot szoktam kiadni: 


Eterm -O -e sudo tail -f 
/var/log/httpd/access log 


A terminálemulátorokhoz ugyan nem 
sok köze van, de megjegyezném, hogy 

a fenti parancs futtatásához hozzá kell 
adnunk magunkat a /etc/sudoers fájlhoz 
— kivéve persze azt az esetet, ha rootként 
futtatjuk az Etermet. Én az alsó sort ír- 
tam hozzá a fájlhoz, közvetlenül a root 
jogainak meghatározása alá: 


f User privilege specification 
5 (Felhasználói jogok meghatározása) 
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2. ábra A GNOME terminál lapjai révén 
takarékoskodhatunk a képernyő 
felületével 





General Title and Command Colors Effects Serolling Compatibility 
Background 
None (use solid color) 
"Background image 
Image file: 
x 


6 Tansparent background 


-§hade transparent or image background: 
Neme anmum 


I dose 


Elie 





3. ábra Ha átlátszó GNOME terminált 
akarunk, először egy profilt kell 
létrehoznunk 


(Session) Edit View 
aiNew Snel 

7 New Window 

dai New Linux Console 
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4. ábra Konsole-lapok, könyvjelzők 
és egyebek 
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5. ábra A Ouadkonsole négy Konsole-t 
indít egy rácson 


Vessünk egy pillantást például a KDE 
Konsole programjára, vagy akár 

a GNOME terminálra. Mindkettőre igaz, 
hogy nemcsak alapszintű héjelérést biz- 
tosít, de lapokra kerülő munkamenetek- 
ben több héj futtatását is lehetővé teszik. 
Ha a GNOME terminálban több lapot 
akarunk használni, nyomjuk meg 

a SHIFT-CTRL-T billentyűkombinációt, 

és máris megnyílik egy új munkamenet 
(2. ábra). 

A GNOME terminál ugyancsak támo- 
gatja az átlátszóságot, vagyis, ha olyan 
parancsfájlt akarunk indítani, amely 

a kedvenc háttérképünk felett gördíti 

a naplók tartalmát, ezt is megtehetjük. 
A GNOME terminál esetében ezek 

a szolgáltatások profilok révén érhetők 
el. Ha létre szeretnénk hozni egy profilt, 
kattintsunk a GNOME terminál menü- 
sorának Edit (Szerkesztés) elemére, majd 
válasszuk a Profiles (Profilok) parancsot. 
Kattintsunk a New (Új) elemre, majd ad- 
junk a profilnak egy nevet, mint például 
atlatszo". Miután az Editing Profile 
(Profil szerkesztése) párbeszédpanel 
megjelent, kattintsunk az Effects 
(Hatások) fülre, majd a Transparent 
background (Átlátszó háttér) választó- 
gombra (3. ábra). 

A csúszka segítségével állítsuk be 

az átlátszóság szintjét, majd zárjuk 

be a profilablakot. Ez után a következő 
paranccsal indíthatjuk el a GNOME 
terminált: 


gnome-terminal --window-with 
5 -profile-atlatszo NM 

-e "sudo tail -f 

5 /var/1log/messages" 


Ha tetszik az eredmény, a fenti paran- 
csot írjuk be egy parancsfájlba, aminek 
persze adjunk egy általunk értelmesnek 
tartott nevet. 

A KDE világában a Konsole áll rendelke- 
zésünkre, mely szintén kiválóan kezeli 

a lapokat. Ha új lapon szeretnénk Konsole 
munkamenetet indítani, kattintsunk 

a menü Session (Munkamenet) elemére, 
majd válasszuk a New Shell (Új héj) pa- 
rancsot. A lapokat duplán rájuk kattintva, 
majd névvel ellátva szabhatjuk testre. 





root ALL-(ALL) ALL 
marcel  ALL-(ALL) ALL 


A terminálprogramok újabban egy másik izgalmas szolgál- 
tatást is támogatnak, és ez a lapok kezelése. Lapok alkalma- 
zásával nincs szükség több terminálprogram elindítására, 
vagyis jóval kevesebb felületre van szükség a képernyőn. 
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Ha több héjat is futtatunk — például az egyik helyen progra- 
mot fordítunk, a másikban figyelünk valamit, a harmadikban 
pedig rootként tevékenykedünk -, akkor a lapok elnevezése 
fontos kényelmi szolgáltatás lehet. Megjegyezném még, hogy 
a Session menüre kattintva számos egyéb beállítást és lehető- 
séget is elérhetünk, mint például a könyvjelzővel jelölt helyen 
történő munkamenet-indítás (4. ábra). 








EJ -PSTREE (1) 
User 


Conmands 
PSTREE(1) 


NAME 
pstree - display a tre 
f 
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6. ábra Ha túl sok információt kellene befogadnunk, 


a Ouadkonsole segítségünkre siet 


Könyvjelzők? Miközben rendszergazdai teendőinket végez- 
zük, egy idő után észrevesszük, hogy újra és újra ugyanazok- 
ba a könyvtárakba kell belépnünk. Persze, gyorsan gépelünk, 
így bárhova pillanatok alatt eljutunk, könyvjelzőkkel mégis 
könnyebb. Amikor éppen a könyvtárfa sokadik szintjén lévő, 
mégis sokszor használt könyvtárban vagyunk, kattintsunk 

a menüsorra, majd az Add Bookmark (Könyvjelző hozzáadása) 
parancsra. A megjelölt helyhez nevet is rendelhetünk, majd 
a későbbiekben egyetlen kattintással megnyithatunk egy 
héjat az adott könyvtárban. 

Természetesen nem léphetünk tovább úgy, hogy az átlát- 
szóságról ne essék szó. A Konsole-ban az átlátszóságot 

a menüsor Settings (Beállítások) elemére és a Schema 
(Séma) parancsra kattintva, majd az egyik átlátszóságot ki- 
választva engedélyezhetjük. Miközben a Settings menüben 
mozgunk, bizonyára észre fogjuk venni, hogy a Konsole 
terminálprogram számtalan beállítással rendelkezik. 
Megváltoztathatjuk a betűkészletet, átválthatunk teljes 
képernyős módra, megváltoztathatjuk a kódolást és 

a billentyűzet kiosztását, továbbá riasztásokat adhatunk 
meg arra az esetre, ha a lapokon futó munkamenetekben 
valamilyen változás állna be. Senkit nem fosztanék meg 

a Konsole önálló megismerésének örömétől, de hadd mu- 
tassak egy parancsfájlt, amivel letisztult, átlátszó Konsole-t 
indíthatunk a naplófájl figyelésére: 


konsole --schema Transparent.schema --nomenubar NM 
--notabbar --noframe NM 
-e sudo tail -f /var/log/messages 


Mai menünk utolsó fogása egy nagyszerű program lesz 

— egész egyszerűen nem is értem, korábban hogyhogy 
nem láttam még hasonlót sem. Miután felfedeztem, azon- 
nal rendszeresen használni kezdtem, és azóta sem akarok 
megválni tőle. A KDE kpartsra építve Simon Perreault 
Ouadkonsole névvel új programot írt. Mint neve is utal rá, 
négy Konsole programot indít el egy rácsozatban (5. ábra); 
így nincs szükség arra, hogy a Konsole ablakait egymás 
mellé rendezzük vagy a héjak között a lapokra kattintva 
váltogassunk. További szépsége, hogy a Ouadkonsole 

a tálcán egyetlen programként jelenik meg, vagyis 
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a Kicker panel áttekinthető marad. Ez különösen 
hasznosnak bizonyul majd, ahogy tovább ismerkedünk 

a programmal. 

Mindegyik futó Konsole-t kívánságunk szerint módosíthat- 
juk, ehhez rá kell kattintanunk a jobb oldali egérgombbal, 
ki kell választanunk a Settings (Beállítások) parancsot, 
majd végre kell hajtanunk a megfelelő változtatásokat. 
Megtehetjük például, hogy az egyik ablakot átlátszóra állít- 
juk, a másikban fekete háttéren kisebb méretű, fehér betűk- 
kel írunk és így tovább. Tulajdonképpen mindegyik ablak 
egy önálló Konsole példány, és beállításait is ennek megfe- 
lelően változtathatjuk. 

Ha ez sem elég, a Ouadkonsole-t négynél több Konsole-lal is 
indíthatjuk, ehhez csak meg kell adnunk a sorok (rows) és 
az oszlopok (columns) számát: 


aguadkonsole --rows 4 --columns 4 


A fenti parancs hatására a Ouadkonsole pontosan 16 különál- 
ló terminálkapcsolattal indul (6. ábra). Éppen ez az, amikor 

a Kicker panel tisztán tartása jól jön. Nyilván, ha azt akarjuk, 
hogy az információk tényelegesen el is férjenek a képer- 
nyőnkön, akkor érdemes eljátszanunk a betűméretekkel. 
Nálam például az egyik ablakban a top egy különösen kis- 
méretű betűtípussal valós időben figyeli a folyamatokat és az 
erőforrások használatát. Igaz, ha látni akarok belőle valamit, 
elő kell vennem a nagyítót - erre van például a kmag. 
Alapesetben a fókusz követi az egérmutatót, ebből furcsa 
balesetek származhatnak, ha gépelés közben véletlenül meg- 
lökjük az egeret. Az alapbeállítást érdemes tehát felülbírálni, 
erre a Ouadkonsole indításakor használható --clickfocus 
kapcsoló használható. Alkalmazásakor egy-egy Konsole kivá- 
lasztásához rá kell kattintanunk a megfelelő ablakra. 

Én is a kattintásos fókuszváltást szeretem, csakhogy sokszor 
idegesítő tud lenni, ha folyton az egérért kell nyúlkálni. 
Szerencsére a Ouadkonsole erre is kínál megoldást, 

a Konsole példányok között a SHIFT-CTRL-kurzorgombok 
kombinációval tudunk fel, le, jobbra és balra váltogatni. 
Incroyable! Úgy tűnik, mes amis, ismét elérkezett a záróra. 
Bár tudna valaki írni egy olyan programot is, ami sza- 
badidőnk egyetlen órácskájából négyet, vagy akár 16-ot 
varázsolna! Itt a rengeteg finom bor és a számtalan kiváló 
program, volna mit ízlelgetnünk, ha időnk engedné. 
Semmi baj, mes amis, egy kis idő még belefér, és csevegés 
közben Francois örömmel tölti újra poharatok. Dőljetek 
hátra, és élvezzétek a Cóte du Rhóne zamatát! Emeljük fel 
poharunkat, mes amis, és igyunk egymás egészségére! 

A votre santé! Bon appétit! 


Linux Journal 2005. július, 135. szám 


A cikkhez tartozó források elérhetősége: 
5 www.linuxjournal.comjarticle/8259 


Marcel Gagné (mggagneOsalmar.com) 
Mississaguában, Ontario államban él. 

Ő a szerzője a Kiskapu kiadásában tavaly szep- 
temberben megjelent Linux-rendszerfelügyelet 
(ISBN 96-9301-40) című könyvnek. 
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Egy szabadalmi irányelvtervezet 


ntündöklése" és bukása 


2005. július 6. emlékezetes nap lesz a szabad szoftverek történelmében. 
A mai napon ugyanis 648 nem szavazattal, 14 ellenében, 18 tartózkodás 
mellett az Európai Parlament elvetette a számítógéppel megvalósított 
találmányok szabadalmazására vonatkozó (ismertebb nevén: szoftver- 


szabadalmi) irányelvtervezetet. 


Egyszer volt, hol nem volt.... 

A történet 1973-ban kezdődik, az Európai Szabadalmi 
Egyezmény müncheni aláírásával, mikoris az egyezmény 
szövegébe bekerül az alábbi részlet: 





A vastagon szedett szavak Németország közbenjárás- 
ára kerültek az irányelv szövegébe, habár senki sem 
tudta pontosan, mit is kéne érteni a , számítógépi 
program, mint olyan" kifejezés alatt. Az évek azonban 
megmutatták, hogy az Európai Szabadalmi Hivatal 
hajlamos arra az értelmezésre, hogy e kizáró tényező 
alkalmazását a lemezen vagy egyéb hordozón benyúj- 
tott kódra alkalmazza, amennyiben azt semmi egyéb 
dokumentáció vagy leírás nem kísérte. Amennyiben 
azonban a kacifántos körmondatokban megfogalmazott 
igénypontokból azt lehetett kivenni, hogy a szoftveres 
megoldás valójában egy ártatlan eljárási szabadalom, 
ami ezáltal nem eshet kizárás alá, hiszen számítás- 
technikai, műszaki eljárások szabadalmazása egyáltalán 
nem volt tiltott. 

Ez vezethetett oda, hogy napjainkban egy német, szabadal- 
mi ügyekkel foglalkozó iroda ügyvédje kijelenthette: 
bármi, ami tartalmaz újdonságelemet szabadalmazható, 
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csak jól kell megfogalmazni." Figyelemmel arra, hogy volta- 
képpen valamennyi szoftver , eljárás", e tulajdonságainak 
részletezése szakavatottak számára nem jelenthet különö- 
sebb problémát. 


Lássunk pár példát 

A Parlament javaslatai között szerepelt, hogy az irányelv- 
tervezetet magát nevezzék át, hiszen a számítógéppel 
megvalósított találmányok félrevezetőek, hiszen azt sej- 
tetik, hogy a találmánynak magán a számítógépen kell 
megvalósulnia (azaz nyilván a gépen futó szoftverek for- 
májában). Ezért a javasolt fogalom: , számítógéppel vezérelt" 
találmányok lett volna. 

A Tanács például nem támogatta azt a megoldást, 

mely szerint a szabadalmazás feltételének kellene 
tekinteni valamely, a fizikai világgal való kapcsolat, 
ami jelezné, hogy a , találmány" többre képes, mint 
holmi adatkezelés. 


Az irányelv múltja 

Az irányelv iránti igény az ezredforduló körül ütötte 

fel a fejét, és 2002-ben nyerte el első alakját. Az Európai 
Bizottság tehát a tagországok szabadalmi jogának har- 
monizálását szem előtt tartva megalkotta az irányelv- 
tervezet első változatát és 2002. szeptemberében előter- 
jesztette azt. Miután kézhez kapta, a Parlament 2003 
szeptemberben alaposan teletűzdelte módosító indít- 
ványokkal (64 darab került elfogadásra) a szöveget 

és véleményét megküldte a Tanácsnak, ahol azonban 
semmibe vették az említett javaslatokat igyekeztek ki- 
alakítani az úgynevezett , közös álláspontot", melynek 
elfogadásához minősített többségre volt szükség. Az új 
tagállamok csatlakozása és a módosított szavazatszámok 
okoztak némi fennakadást (emlékezzünk csak a lengye- 
lek ideiglenes blokkolására 2004. decemberében a Mező- 
gazdasági és Halászati Miniszterek Tanácsában). 2005. 
februárjából ismert a Parlament hiábavaló kísérlete, 








melyben kezdeményezte a szöveg Bizottság általi 
visszavonását és újragondolását. 2005. március 7-én 
sikerült aztán megfelelő többséget találni az irányelv 
elfogadásához, ehhez kellett egy spanyol ellensza- 
vazat, Ausztria, Belgium és Olaszország 
tartózkodása valamint a többi tagállam 
— köztük hazánk - igen szavazata. 
Ezt követte az utolsó forduló. 

Az anyagot megküldték a Parlament- 
nek, akinek 3 hónapja volt a fel- 
készülésre. Ez alatt 256 módosító 
indítvány érkezett be, ezek egy 
része átfedésben egymással. 

A legátfogóbb (és szövegében 
legtámogathatóbb) módosítás 
csokrot Michel Rocard nyújtot- 
ta be. A tanácsi szöveggel kap- 
csolatos elégedetlenséget jelez- 
te, hogy az irányelv tervezet 
majd valamennyi pontját érin- 
tette módosítási indítvány. 
Érdekes megjegyezni, hogy 2, 

a kis és középvállalkozások ér- 
dekeinek védelmét előmozdító 
módosítás például magyar kép- 
viselőktől származott. 


Az irányelvjavaslat sebei 
Az irányelvjavaslat szövege egyébként 
olyan komplikáltra sikerült, hogy okos, és 
a témában járatos emberek akár órák 
hosszat el tudtak vitatkozni rajta, avatatlan 
külső szemlélők pedig nem is merészkedtek 
a közelébe. Fő hibái, hogy jogászok technikai fogalmak- 
kal próbáltak megküzdeni ráadásul a szabadalmi jog 
hálójába bonyolódva. Bár eredeti célja a jogterületre 
vonatkozó harmonizáció lett volna, gyakorlatilag csak 
összezavarta a szálakat. Az állóvíz felbolydult, és hiába 
hangsúlyozták a szabadalmi hivatalok képviselői, hogy 
ez az egész a jelenlegi , status guo" fenntartására irányuló 
kísérlet, már senki sem hitt nekik. 

Beépítette ugyan a Tanács a ,számítógépi program, 
mint olyan" nem szabadalmazható frázist, ugyanak- 
kor félreértések gócpontja ként tartalmazta az alábbi 
szöveget is: 





www.linuxvilag.hu 



















Felszínre kerültek hibásan bejegyzett szabadalmak, 
megsajdult a kis- és középvállalatok szíve és pénztárcá- 
ja, mikor megtudták, hogy az európai szabadalmi eljárás 
átlagos költsége 29.000 euró (több, mint 7 millió 
forint). Kibukott, hogy az újdonságkutatá- 
sok alapját a szoftveróriások által rendel- 
kezésre bocsátott adatbázisok illetve 
a már bejegyzett szabadalmak kézik, 
ezért Európaszerte kísérleteket 
tettek a szabad szoftverek do- 
kumentált közzétételére, hogy 
bizonyítható legyen bármelyik 
bíróság előtt, ,a levédett szoft- 
ver nem új" és így védelemre 
sem érdemes. 
Fontos tudni a szabadalmi 
oltalomról, hogy rendszeres 
díjfizetés mellett a védelem 
20 éven át megilleti a szaba- 
dalmast és valamennyi, 
a szabadalmat használni 
vágyó köteles neki licencdíjat 
fizetni, vagy vállalni a szaba- 
dalombitorlással kapcsolatos 
eljárás megpróbáltatásait. 


A Parlament visszavág 
Tony Robinson szavait szabadon 
idézve: 


Jobb, ha nincs irányelv, mintha 
az ami van, rossz." 


A Parlament tiszta lapot adott a témának. Időt arra, hogy 

a Bizottság és a Tanács átgondolhassa a történteket és ha 
eljön az ideje, egy jó, mindenki számára hasznos szöveggel 
próbálkozzon újra. Hiszen voltak most is jó gondolatok, 
mint az Európai Szabadalmi Hivatal feletti bírósági kontroll, 
vagy a számítógéppel vezérelt találmányok szabadalmazá- 
sára vonatkozó gondolat. 


A háború folytatódik 
Hadd idézzem egy kedves barátomat, aki euforikus 
örömöm hallatán csendesen megjegyezte: 


Ma nyertünk egy csatát. 
De a háború folytatódik." 


Ünnepeljünk hát, de tudjuk, hogy harcolni kell majd 
megint, mindaddig, míg egy korrekt szabályozás nem szü- 
letik. Most jönnek majd a mindennapok apró csetepatéi, 
egy-egy csendesen bejegyzett szoftverszabadalom elleni 
küzdelem. Fegyverbe hát! 


g Dr. Dudás Ágnes (dudas.agnes(ogabend.hu) 

kh ügyvédjelölt, az FSF egyik aktivistája. 2004-ben 
végzett az ELTE Jogtudományi Karán. Szakdol- 
gozatát a szoftverek szerzői jogi védelméről 
írta, a 2003-as évet pedig e terület kutatásával 
a berlini Humboldt Egyetemen töltötte. 
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